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Foreword 

This Technical Specification (TS) has been produced by ETSI Project Broadband Radio Access Networks (BRAN). 

The present document describes the extension of the basic specifications of Data Link Control (DLC) of HIPERLAN/2 
systems for home applications. Separate ETSI documents provide details on the system overview, the physical layer, the 
basic DLC layer functions, the convergence sublayers and the conformance test requirements defined for 
HIPERLAN/2. 

The present document is part 4 of a multi-part deliverable covering the Broadband Radio Access Networks (BRAN); 
HIPERLAN Type 2; Data Link Control (DLC) Layer, as identified below: 

Part 1: "Basic Data Transport Functions"; 

Pai-t 2: "Radio Link Control (RLC) sublayer" ; 

Part 3: "Profile for Business Environment"; 

Part 4: "Extension for Home Environment"; 

Part 5: "Profile for Home Environment". 



Introduction 



The H/2 system is confined to the two lowest layers of the open systems interconnection (OSI) model, the physical 
(PHY) and the Data Link Control (DLC) layer. An overall description of the HIPERLAN/2 system is given in 
TR 101 683 (see bibliography). The PHY layer is described in TS 101 475 [3]. 

The basic DLC layer functions are specified in two different documents (TS 101 761-1 [1] and TS 101 761-2 [2]). 
Document TS 101 761-1 [1] describes Transport and Logical Channels, Error Control, MAC, and mapping between 
PHY and MAC of H/2 system. Document TS 101 761-2 [2] deals with Radio Link Control (RLC) protocols to control 
radio resources, terminal association and connection establishment. The inter-working with higher layers is handled by 
Convergence Layers (CLs) on top of the DLC layer. The common part of packet and cell based convergence layers are 
defined in TS 101 493-1 and TS 101 763-1 (see bibliography), respectively. 
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Scope 



The present document specifies the extension of the basic DLC layer functions in TS 101 761-1 [1] and 
TS 101 761-2 [2] for direct mode operation in home environment. This DLC home extension specification gives first an 
overview of the HIPERLAN/2 home system concept. It then describes additional rules and elements to transport DM 
data over the channels introduced in TS 101 761-1 [1]. Forward Error Correction (FEC) is introduced in the DLC layer 
to achieve a much lower bit error rate for isochronous packet transport without ARQ. The present document also 
extends the RLC protocols in TS 101 761-2 [2] to support Constant Bit Rate (CBR) traffic by fixed slot allocation, to 
enable parameter negotiation for multicast connections, to enable association of multiple CLs for wireless terminals, 
and to enable Direct Link (DiL) Power Control. Furthermore, It describes some RLC protocols which are only specific 
for DM operation in home environment, such as DiL Link Quality Calibration, Dynamic CC Selection, and CC 
Responsibility Handover. Besides, a PIN and time-window based authentication key distribution protocol is specified 
for HIPERLAN/2 Home Devices (H/2-HDs). The DM services can be used by the IEEE 1394 CL (TS 101 493-3 and 
TS 101 493-4 (see bibliography)) for wireless bridging of different IEEE 1394 buses. 

The present document does not contain algorithms, which are only performed locally in a device, but describes rules 
and elements to transport data over the air interface. The goal is to provide interoperability between devices of different 
manufacturers. 

The present document does not address the requirements and technical characteristics for conformance testing. These 
are covered in a separate set of documents. 
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Link Control (DLC) Layer; Part 1: Basic Data Transport Functions". 

[2] ETSI TS 101 761-2: "Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Data 

Link Control (DLC) Layer; Part 2: Radio Link Control (RLC) sublayer". 

[3] ETSI TS 101 475: "Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Physical 

(PHY) Layer". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Access feedback CHannel: transport channel where the results of access attempts made in the random access phase of 
the previous MAC frame is conveyed 

Association Control Function: group of control functions on top of the RLC that is responsible for the handling of the 
association between WT and CC 

Association control CHannel: logical channel in uplink that conveys new association and re-association request 
messages 
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Access Point: term Access Point used in the basic specifications is replaced by the term Central Controller throughout 
TS 101 761-4 (VI. 3. 2) to reflect that in home environment multiple H/2 devices can act as the access point to a fixed 
network, whereas the whole H/2 network is still controlled by a single entity, the Central Controller 

Basic WT: H/2 home device, which is able to associate with a CC and to communicate with the CC in the control plane 
and with other H/2 home devices in the user and control planes. A basic WT is unable to become the CC. 

Broadcast CHannel: transport channel that broadcasts control information 

Broadcast Control CHannel: logical channel that broadcasts control information which is relevant for the current 
MAC frame 

CC-capable WT: H/2 home device, which can act either as a Central Controller, or as a basic WT. When it is acting as 
the CC with respect to the control plane, it supports all features of a basic WT. 

Central Controller: provides control functionality equivalent to that of an access point in TS 101 761-1 and 
TS 101 761-2 but is not necessarily attached to a fixed network. This term is used where the central controller 
functionality is embedded in a WT. 

Centralized Mode: in centralized mode, all data transmitted or received by a mobile terminal have to pass the 
centralized controller, even if the data exchange is between mobile terminals associated to the same centralized 
controller 

DLC Connection: HIPERLAN/2 DLC operation is connection oriented. A DLC connection carries user or control data 
and is identified by a DLC connection identifier. 

DLC User Connection: DLC user connection is uniquely identified by the DLC connection ID and the MAC ID of the 
mobile terminal in CM. In DM two MAC IDs are necessary 

DLC User Connection Control: group of control functions on top of the RLC that is responsible for the handling of 
DLC user connections 

Downlink phase: part of the Downlink transmission of a MAC Frame during which user and control data is transmitted 
from the access point or central controller to mobile terminals 

NOTE: The data transmitted can be user as well as control data in unicast, broadcast and multicast modus. 

Direct Mode: data exchanged between two WTs associated with the same CC takes place without passing but under 
control of the central controller 

Direct Link phase: part of a MAC frame that only contains the data exchanged directly between two WTs in a direct 
link 

Encryption Function: function that is responsible for keeping user data and part of RLC signalling between WT and 
CC in centralized mode and between WTs in direct mode confidential 

Error control: responsible for detection of transmission errors and, where appropriate, for the retransmissions. One 
error control instance is provided per DLC connection. 

Frame CHannel: transport channel that is broadcast and which carries the frame control channel 

Frame Control CHannel: logical channel that contains the information how the resources are allocated in the current 
MAC frame 

NOTE: Its content changes in general dynamically from frame to frame. 

H/2 Home Device: device which supports at least the mandatory features in the H/2 basic specifications TS 101 761-1 
and TS 101 761-2 and the home extension features in the TS 101 761-4 

NOTE: There are two types of H/2 home devices: basic WT or CC-capable WT. This generic term is also used if 
no difference is made between the device acting as the CC and the devices acting as WTs. 
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logical channel: generic term for any distinct data path 

NOTE: A set of logical channel types is defined for different kinds of data transfer service as offered by MAC. 
Each logical channel type is defined by the type of information it carries. Logical channels can be 
considered to operate between logical connection end points. 

MAC frame: periodical structure in time that appears on the air interface and that determines the communication of 
HIPERLAN/2 devices 

NOTE: It consists of a sequence of traffic channels and its composition has to follow a number of rules. 

Mobile Terminal: the term Mobile Terminal used in the basic specifications is replaced by the term Wireless Terminal 
throughout TS 101 761-4 (VI. 3. 2) to reflect that in home environment not all H/2 terminals need to be mobile 

non HE-compliant device: H/2 device, which meets the basic DLC specifications in TS 101 761-1 and TS 101 761-2 
but not the DLC HE specification in the TS 101 761-4 

PDU train: sequence of transport channels delivered to the physical layer 

PHY mode: PHY mode corresponds to a signal constellation (modulation alphabet) and a code rate combination 

Random Access CHannel: logical channel in the uplink of the MAC frame in which the WTs can send signalling data 
for the DLC or the RLC 

Random CHannel: transport channel in the uplink of the MAC that carries the logical channels random access channel 
and association control channel 

Random access Feedback CHannel: logical channel where the result of an access attempt made in the previous MAC 
frame is conveyed 

Random Access phase: period of the MAC Frame where any WT can try to access the system 

NOTE: The access to this phase is based on a contention scheme 

Radio Link Control sublayer: control plane of the DLC, which contains control protocol that offers transport services 
for the RRC, ACF and DUCC 

Radio Resource Control: group of control functions on top of the RLC that is responsible for the handling of radio 
resources 

Resource Grant: allocation of transmission resources by a central controller 

Resource Request: message from a terminal to a central controller in which the current buffer status is transmitted to 
request for transmission opportunities in the uplink or direct link phase 

subnet: smallest configuration in an H/2 home system, which is characterized by an active CC sending BCCH on a 
certain frequency 

NOTE: A subnet is created after a CC is selected and ready to accept association requests from other H/2-HDs. 

Transport Channel: basic element to construct PDU trains. Transport channels describe the message format. 

UpLink phase: part of the MAC frame in which data is transmitted from mobile terminals to a central controller 

Wireless Terminal: H/2 home device, which is not acting as a central controller for a subnet 
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3.2 Symbols 



For the purposes of the present document, the following symbols apply: 



Fp 

TScAN 

Tps 
P 

g(x) 
P(x) 



Probing Frame 

Frequency Scanning Time (per frequency) 

Frequency Switching Time 

Probing Period 

Code Generator Polynomial 

Field Generator Polynomial 



3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ABIR ARQ Bandwidth Increase Request 

ACF Association Control Function 

ACH Access feedback CHannel 

AP Access Point 

ARE ARQ feedback message request Bit 

ARQ Automatic Repeat ReQuest 

ASCH Association control CHannel 

BCCH Broadcast Control CHannel 

BCH Broadcast CHannel 

BE Business Extension 

BER Bit Error Rate 

CC Central Controller 

CL Convergence Layer 

CM Centralized Mode 

CRC Cyclic Redundancy Code 

C-SAP Control Service Access Point 

DCCH Dedicated Control CHannel 

DES Data Encryption Standard 

DFS Dynamic Frequency Selection 

DiL Direct Link 

DL DownLink 

DEC Data Link Control 

DLCC DEC Connection 

DM Direct Mode 

DUC DEC User Connection 

DUCC DEC User Connection Control 

EC Error Control 

EC Flow Control 

FCA Fixed Capacity Agreement 

FCCH Frame Control CHannel 

FCH Frame CHannel 

EEC Forward Error Correction 

FSA Fixed Slot Allocation 

FSA-RG Fixed Slot Allocation Resource Grant 

H/2 HIPERLAN type 2 

H/2-HD H/2 Home Device 

HE Home Environment 

HEE Home Environment Extension 

IE Information Element 

IV Initialization Vector 

ECCH Link Control CHannel 

ECH Long transport CHannel 

LSB Least Significant Bit 

MAC Medium Access Control 

MAC-ID MAC-IDentifier 

MD5 Message Digest #5 
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MSB Most Significant Bit 

MT Mobile Terminal 

NET-ID NETwork-IDentifier 

NOP -ID Network OPerator IDentifier 

OCC Optional CC 

OFDM Orthogonal Frequency Division Multiplexing 

OWT Optional WT 

PC Power Control 

PDU Protocol Data Unit 

RACH Random Access CHannel 

RBCH RLC Broadcast CHannel 

RCH Random CHannel 

RFCH Random access Feedback CHannel 

RG Resource Grant 

RLC Radio Link Control protocol 

RR Resource Request 

RRC Radio Resource Control 

RSS Received Signal Strength 

RSS2 RSS measured in Direct Mode 

SAP Service Access Point 

SCH Short transport CHannel 

SSK Session Secret Key 

UBCH User Broadcast CHannel 

UDCH User Data CHannel 

UL UpLink 

UMCH User Multicast CHannel 

U-SAP User Service Access Point 

WT Wireless Terminal 



Overview 



4.1 



H/2 home network architecture 



The H/2 home network is compliant to the ETSI/BRAN framework architecture, namely each H/2 device consists of the 
PHY, the DLC, and one or multiple CLs. The home environment specific DLC services are realized based upon the 
basic functions specified in TS 101 761-1 [1], TS 101 761-2 [2] and TS 101 475 [3], and the DLC HE functions 
specified in the present document. The application layer in an H/2 home device makes use of the DLC services through 
an application specific CL. In particular, the 1394 CL (TS 101 493-3 and TS 101 493-4 (see BibHography)) is used to 
support IEEE 1394 based applications. 

4.1.1 The single subnet model 

Unlike infrastructure based configuration, the H/2 home system is designed as an adhoc LAN, which can be put into 
operation in a plug-and-play manner. The H/2 home system utilizes the H/2 basic features in TS 101 761-1 [1] and 
TS 101 761-2 [2] by defining the following equivalence between the adhoc LAN configuration and the infrastructure 
based configuration: 

• a subnet in the adhoc LAN configuration is equivalent to a cell in the infrastructure based configuration; 

• a central controller in the adhoc LAN configuration is equivalent to the access point in the infrastructure based 
configuration. 

Thus, the smallest configuration in an H/2 home system consists of a single subnet. It is assumed that a single subnet is 
enough to cover near future applications in typical private homes. At each point in time only one H/2 WT can act as the 
CC in a subnet. 
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A subnet is created when the CC starts to generate valid BCCH, and allows other devices to associate with the network. 
All devices of a subnet shall be synchronized to the frequency chosen by the CC, and access the channel using the MAC 
frame structure given in BCCH and FCCH by the CC. The selection of the CC is dynamic, and seamless handover of 
the Central Controller (CC) responsibility from one CC-capable WT to another is possible. 

To obtain a unified control framework for both infrastructure and adhoc modes of operation, the control plane is kept 
centralized for all general features in ad hoc mode. That means that only the CC can instruct a WT to do something. 
However, distributed control is also made possible for some home extension features by introducing logical control 
channels, which can be used for direct exchange of control messages between WTs. 

In the user plane, H/2 ad hoc mode makes extensive use of direct link user connections. This significantly improves the 
resource efficiency, since in a typical home environment most user traffic is of intra-cell nature. As in the infrastructure 
mode, the 8-bit MAC -ID is used to differentiate devices in a subnet, and the 6-bit DLCC-ID plus the source and 
destination MAC-IDs are used to differentiate connections between a pair of devices, or broadcast/multicast 
connections originating from any WT in ad hoc mode. 

The present document deals only with a single subnet model, in which each WT can listen to the CC. This ensures that 
the control plane functions specified in TS 101 761-1 [1] and TS 101 761-2 [2] are mostly reusable. For user plane, DM 
is used, provided that two WTs can reach each other directly. A link quality calibration process helps to track the 
connectivity between any two devices by measuring the associated RF link quality. The CC is used as a user data relay 
for a pair of WTs, if direct link between these two WTs is not possible. Even this user data relaying is performed during 
the direct link phase between the WTs and the CC. 

The above single subnet model can be extended to support hidden terminals. In the context of the H/2 home system, 
hidden terminals are defined as terminals that cannot directly listen to the CC. However, hidden terminal support is 
beyond the scope of this release of the DLC HE specification. 

4.1 .2 The multiple subnets model 

If the capacity of a single subnet is insufficient, or the home is too large to be covered by a single subnet, multiple 
subnets operating on different frequencies can be applied. Each subnet is under the control of its own CC, and works 
independently of the other subnet(s). DFS is used to enable dynamic selection of the RF channel. Different subnets are 
differentiated by different AP-IDs, and all subnets belonging to the same owner shall use the same NET-ID. 

Different subnets can be interconnected either by a fixed network, or by H/2 bridging devices. Since user connections 
can be set up directly between any two WTs in a subnet, it is not necessary to use the CC to forward user traffic 
between different subnets. Potentially any device in a subnet can be configured as a bridging device to another subnet. 
A WT can associate with two overlapping subnets to become the bridging node between these subnets, provided it can 
be synchronized to the BCCHs of the two subnets alternatively. 

The inter-cell handover procedure specified in TS 101 761-2 [2] can be utilized to support mobility of H/2 home 
devices beyond the boundary of a single subnet. Inter-cell handover can be done either with or without fixed network 
support. 

Support for multiple subnets is beyond the scope of this release of the DLC HE specification. 



4.2 Service types to be supported 



The H/2 DLC services are generic to support a variety of high-speed multimedia applications. Features especially 
important for home environment include, but are not limited to: 

• connection oriented high speed transmission for all application types; 

• low delay, low delay jitter, and low bit error rate delivery of real time packets; 

• isochronous and asynchronous services; 

• acknowledged and unacknowledged asynchronous packet transfer; 

• adhoc networking with QoS support; 

• access to external networks (e.g. ADSL, DVB) from any H/2 home device; 
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• dynamic frequency selection and power control; 

• user-friendly security concept. 

These features are enabled by the present document together with TS 101 761-1 [1], TS 101 761-2 [2] and 
TS 101 475 [3]. In later releases, the H/2 home system intends to provide: 

• mobility support; 

• hidden terminal support; 

• multiple subnets interconnect; 

• directional antennas; 

• add-on CL servers for different types of applications. 

For each type of applications, a convergence layer is required to convert the DLC SDU into a format, which is 
accessible by the specific application layer, and vice versa. Support for Ethernet, IEEE 1394 and ATM based 
applications is specified in TS 101 493-1, TS 101 493-2, TS 101 493-3, TS 101 493-4, TS 101 763-1 and TS 101 763-2 
(see Bibliography). Support for other applications, such as USB-based applications, can be added later on. 

4.3 Types of devices supported 

For ad hoc networking in home environment two, and only two H/2-HDs types are defined for the single subnet model: 

• Basic WT; 

• CC-capable WT. 

A basic WT is a user device that is able to associate with a CC and to communicate with the CC and other WTs in the 
control plane, and with other H/2-HDs in the user plane under the control of the CC. A basic WT consists of all DLC 
layer functions defined by the basic specs in TS 101 761-1 [1] and TS 101 761-2 [2] plus functions defined in the 
present document. A basic WT supports Direct Mode. 

A CC-capable WT can act either as a Central Controller, or as a basic WT. When it acts as the CC, it is capable of 
performing all control plane functions specified in TS 101 761-1 [1], TS 101 761-2 [2] and in the present document for 
the role of AP, or CC, respectively. Furthermore, for each supported CL all required CL functions at the AP side, or 
CC side, respectively, need to be implemented in the CC-capable WT. A CC-capable WT acting as CC is also able to 
communicate with other WTs in the user plane as a basic WT. That means that it supports all basic WT functions, 
additionally. 

The acting CC for a subnet is dynamically selected among all active CC-capable WTs. User interaction to prefer a 
special CC-capable WT to become the active CC is possible. Seamless handover of the CC responsibility from one 
CC-capable WT to another is also possible. 
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5 DM transmission and reception functions 

(OCC/OWT) 

If Direct Mode is supported, it shall be performed as described below. 

5.1 Logical channels and their characteristics 

H/2 home devices shall support all logical channels defined in clause 5.1 and clause 6.1 of TS 101 761-1 [1]. Direct link 
UDCH, LCCH, UBCH, UMCH, DCCH and RBCH shall also be implemented. The DiL UDCH and DiL LCCH shall be 
used for unicast user communication between any two H/2-HDs, and the associated link control, respectively. The DiL 
UBCH and DiL UMCH shall be used for user broadcast from any one H/2-HD to all other H/2-HDs supporting the 
same CL, and for user multicast from any one H/2-HD to a group of other H/2-HDs, respectively. DiL DCCH shall be 
used for RLC message exchange between any two H/2-HDs, or from a DM sender to a group of DM receivers in case of 
DiL multicast. DiL RBCH shall be used for distribution of RLC messages from any one H/2-HD to all other H/2-HDs. 
UL DCCH is used for the transmission of RLC messages from a WT to the CC, unicast DL DCCH for transmission of 
RLC messages from the CC to a particular WT, and DL RBCH is used for transmission of RLC messages from the CC 
to all WTs. 

In order to use DiL UBCH or DiL UMCH a WT shall perform the respective join procedure in TS 101 761-2 [2]. 

H/2-HDs shall also support downlink multicast using DL DCCH to send control messages from the CC to a group of 
WTs, what is not specified in TS 101 761-1 [1]. In this case, the multicast MAC-ID assigned during the multicast join 
procedure in TS 101 761-2 [2] shall be used for downlink DCCH. 

NOTE: Unlike DiL DCCH, downlink DCCH is identified by a single MAC -ID. 

H/2-HDs shall use DiL UDCH, or DiL UMCH, or DiL UBCH for exchange of user packets with one or more other 
H/2-HD, even if the peer entity is the CC. An H/2-HD may use uplink or downlink UDCH/UMCH/UBCH to send or 
receive user packets, if the peer device is not subject to the home extension specification in the present document. 

5.2 Transport channels and their characteristics 

H/2 home devices shall support all transport channels defined in clauses 5.2 and 6.2 of TS 101 761-1 [1]. Direct link 
LCH and SCH shall also be implemented. The LCH is allocated in the DiL phase to transport user data for the 
connections related to the DiL UDCH, DiL UBCH, and DiL UMCH, and long control packets for the connections 
related to the DiL DCCH and DiL RBCH. The SCH is allocated in the DiL phase to transport short control packets for 
the connections related to the DiL LCCH, DiL DCCH and DiL RBCH. 

Possible PHY modes for different transport channels are given in clause 6.8.1 of TS 101 761-1 [1]. The PHY mode for 
LCH related to DiL UDCH, DiL UMCH, DiL UBCH and DiL DCCH is one of all possible PHY modes as defined in 
TS 101 475 [3]. The PHY mode for LCH related to DiL RBCH is set to the most robust one (BPSK Yi). The PHY mode 
for SCH related to DiL LCCH and DiL DCCH is set to BPSK Yi, or BPSK ¥4, or QPSK ¥4. The PHY mode for SCH 
related to DiL RBCH is set to the most robust one (BPSK Yi). 

5.3 Mapping between logical and transport channels 

The mapping between direct link logical and transport channels is given in clause 5.3ofTS 101 761-1 [1]. Unlike 
centralized mode, the DiL LCCH does not include RR for direct link connections. The RRs for DiL LCH and DiL SCH 
shall be sent on the uphnk DCCH using SCH, or RCH. 
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5.4 Mapping between MAC frame and PHY frame 

The mapping between MAC frame and PHY frame is defined in clause 6.9 of TS 101 761-1 [1]. 

One preamble shall be added at the beginning of each direct link PDU train. The preamble of the direct link PDU train 
shall have a length of 4 OFDM symbols, see TS 101 475 [3]. 

A direct link PDU train shall consist of all LCHs and SCHs belonging to the same pair of source and destination 
MAC-IDs. A set of SCHs and LCHs is granted for each DLCC by one RG. An WT shall receive not more than one 
direct link PDU train containing UDCHs, DCCHs, and LCCHs per MAC frame per source MAC -ID, i.e. all 
corresponding DLCCs shall be grouped in a single PDU train. It may receive the RBCH, UMCHs and UBCHs from the 
same sender in separate PDU trains. Since DCCH can also be used for downlink multicast in the HEE, a WT may 
receive a multicast downlink DCCH and a unicast downlink DCCH in separate PDU trains. 

A guard time between two consecutive DiL PDU trains shall always be inserted by the CC scheduler in order to cope 
with propagation delays, if the two PDU trains have different source MAC-IDs. A guard time may not be inserted if two 
subsequent PDU trains have the same source MAC-IDs. 

The duration of one OFDM symbol is equal to 4 |is if the long cyclic prefix is used, or 3,6 |is if the short cyclic prefix is 
used. Both long and short cyclic prefixes shall be supported by all H/2-HDs. The long cyclic prefix is used for all SCHs 
and LCHs carrying BCCH, FCCH, RFCH, ASCH, RBCH, DCCH, UBCH and corresponding LCCH, and UMCH 
without QoS negotiation by an explicit DUC setup procedure. 

The short cyclic prefix is the default value for all UDCH and UMCH connections, which are setup by an explicit DUC 
setup procedure. If during connection setup not otherwise negotiated, the short cyclic prefix is used for all SCHs and 
LCHs that carry UDCH and the corresponding LCCH, and UMCH with QoS negotiation. 

Within one PDU train SCH and LCH can use different cyclic prefix durations depending on what they carry, for 
example if they carry DCCH and UDCH. 

5.5 DLC addressing for Home Environment 

The general DLC addressing concept in clause 5.6 of TS 101 761-1 [1] applies to the H/2 home devices (home WT and 
CC-capable WT). The MAC -ID is assigned by the acting CC. When a subnet is created, the first active CC also 
internally assigns a MAC-ID to itself. 

For a given DM transmitter, the DiL DLCC-ID is unique for a particular receiver MAC -ID. 

The NET-ID in the BCCH shall be regarded as the owner identifier of the H/2 home system. The NET-ID shall be a 
random number. During the installation process (see clause 6.9), each new H/2-HD device to be installed shall store the 
NET-ID of its network, which is broadcast in the BCCH. Different subnets shall use the same NET-ID. The allowed 
range is to 959. 

When a subnet is to be created, the selected CC shall generate the AP-ID randomly. The device identifier, for example 
the IEEE EUI-64, of this CC shall be used as the seed of the random number generation. However, before the CC starts 
operation, it shall scan all possible frequencies and try to decode the associated BCCH to check if its randomly 
generated AP-ID is already used by another CC. This can be done in combination with the CC selection procedure in 
clause 6.7. A new AP-ID shall be generated, if the old one is already occupied by another CC. 

In this release of the DLC HE TS no sectorized MAC Frame as described in clause 5.4 of TS 101 761-1 [1] is 
considered for the CC. Therefore, Sector-ID = and # of sectors = 1 shall be set in the BCCH. 

The DiL RBCH is identified by the source MAC ID of the transmitting WT, destination MAC ID = and 
DLCC ID = 0. 

The DiL DCCH is identified by the source and destination MAC IDs of the concerned WTs and DLCC ID = 0. 

The DiL UMCH is identified by the source MAC ID of the transmitting WT, the destination multicast MAC ID (in the 
range of 224 to 254) and DLCC ID = 63. 

The DiL UBCH is identified by the source MAC ID of the transmitting WT, the destination broadcast MAC ID (in the 
range of 1 to 223) and DLCC ID = 63. 
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For DiL UDCH, the destination MAC ID is used to identify an outgoing connection for the transmitting terminal and a 
source MAC ID identifies an incoming connection for the receiving terminal. It is permitted to have outgoing simplex 
connections with the same DLCC ID to different destination MAC IDs and to have incoming simplex connections with 
the same DLCC ID from different source MAC IDs. However, between a source and destination MAC ID pair, both 
directions of a bi-directional UDCH shall use the same DLCC ID. 

The DiL LCCH is identified by the source and destination MAC IDs of the concerned WTs and the DLCC ID of the 
related connection. 

The direct link UDCH, LCCH, UBCH, UMCH, DCCH and RBCH are announced in the FCH. 



5.6 Use of DiL logical channels 



5.6.1 Overview of the MAC frame 

The MAC frame structure is given in clause 5.4 of TS 101 761-1 [1]. Support of sectored antennas is beyond the scope 
of the present document. 

The basic MAC frame structure for H/2-HDs is shown in Figure 1 . Each MAC frame shall consist of the transport 
channels BCH, FCH, ACH and at least one RCH. If user data is to be transmitted, a DiL phase shall be provided. If 
downlink control data is to be transmitted (DL RBCH and/or DL DCCH), a DL phase shall be provided. If uplink 
control data is to be transmitted (UL DCCH), an UL phase shall be provided. A BCH, an ACH, a minimum length FCH 
and at least one RCH shall exist in every MAC frame. The duration of the BCH is fixed. The duration of the FCH, DL 
phase, DiL phase, UL phase and the number of RCHs are dynamically adapted by the CC depending on the current 
traffic situation. The order shall be: BCH - FCH - ACH - DL phase - DiL phase - UL phase - RCHs, from the point of 
view of a WT. 

NOTE: The specified order is from a WT's point of view. This means that a CC may e.g. have several DL, DiL, 
and UL phases and mix the phases, as long as the order is kept for each individual WT. 



MAC-Frame 



MAC-Frame 



MAC-Frame 



MAC-Frame 



BCH 



FCH 



ACH DL phase 



DiL phase 



UL phase 



RCHs 



Figure 1 : Direct IVIode lUIAC frame structure 

Detailed rules for the composition of MAC frames are given in clause 6.3.2 of TS 101 761-1 [1]. 

5.6.2 Resource request and resource grant for direct link 

Resource Requests for direct link LCH and SCH are transmitted in RCH or in uplink DCCH using SCH with 
DLCC - ID = 0. No RR for DiL shall be sent in DiL LCCH. The rules for composing and transmitting RR for DiL are 
described in clause 6.2.9.1.2 of TS 101 761-1 [1]. A RR for DiL is always related to a simplex connection whose 
direction is determined by the source and destination MAC-IDs in RRs. 

Resource Grants for direct link LCH and SCH are described in clause 6.2.2.2 of TS 101 761-1 [1]. Like centralized 
mode, they are sent in FCCH. RG for DiL is always related to a simplex connection whose direction is determined by 
the source and destination MAC-IDs in RG. 
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5.6.3 DiLLCCHforARQ 

Direct linkLCCH is defined in clauses 5.1.10 and 6.2.9 of TS 101 761-1 [1]. It is only used for the ARQ protocol 
performed between two H/2-HDs in DM. The acknowledged mode of error control, the ARQ protocol, is described in 
clause 6.4.2 of the TS 101 761-1 [1]. The ARQ protocol of HIPERLAN/2 is symmetric. The ARQ protocol is the same 
for two WTs in DM and for one WT and the CC in DM. ARQ feedback and the discard message for DiL have the same 
format as those for downlink. As in DL LCCH there is no ABIR in the ARQ feedback message in DiL LCCH. This is 
because the receiver of a DiL UDCH is not able to signal an increase in ARQ feedback bandwidth requirement to the 
CC by means of ARQ feedback messages in the DiL LCCH. Thus, the scheduler in the CC has to schedule sufficient 
DiL LCCH resources for ARQ feedback transmission. 

5.6.4 DiL DCCH for RLC 

Direct link DCCH is defined in clauses 5.1.6 and 6.2.5 of TS 101 761-1 [1], and used for RLC message exchange 
between any two H/2-HDs in DM, or from a DM sender to a group of DM receivers. It is mapped to either DiL LCH or 
DiL SCH. This logical channel will be used, for example, by DiL power control and link quality calibration. 

5.6.5 DiL RBCH for RLC 

Direct link RBCH is defined in clauses 5.1.5 and 6.2.4 of TS 101 761-1 [1], and used for RLC message broadcast from 
any one H/2-HD to all other H/2-HDs. It is mapped to either DiL LCH or DiL SCH. This logical channel will be used, 
for example, by link quality calibration. 



5.7 MAC protocol for DM 



In the Direct Mode the direction of logical channels is distributed as shown in Figure 2. 



UL DCCH (RR) 




FCCH (RG) 



DiL LCCH 



Figure 2: Direct IVIode IVIAC protocol principle 

In Figure 2 WT 1 has a DiL connection to WT 2. As in centralized mode Resource Grants (RGs) are transmitted by the 
CC in the FCCH. Resources granted for DiL connections are related to DiL UDCH for User data and related to DiL 
LCCH for ARQ control messages (ARQ feedback and discard). PDUs in the DiL UDCH and discard PDUs in the DiL 
LCCH are directly transmitted from WT 1 to WT 2. ARQ feedback PDUs are directly transmitted from WT 2 to WT 1 . 
The CC does not listen to the DiL UDCH and DiL LCCH if it is not a peer entity of the DiL connection. 

NOTE 1 : The CC itself can act as a WT and thus it can be the source and/or destination of DiL connections. 

Resources for the DiL LCCH in case of ARQ feedback shall not be requested using RRs. The scheduling of sufficient 
resources for ARQ feedback is the task of the scheduler in the CC. 

Resources for the DiL LCCH for transmission of a discard message are requested with a RR for DiL. RRs for DiL are 
transmitted in the RCH or UL DCCH (DLCC - ID = 0). 
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Resource requests shall be used for DiL UDCH, DiL RBCH, DiL DCCH, DiL UMCH, DiL UBCH, and, in case of 
discard messages, also used for DiL LCCH. The rules for generating RR for DiL are described in clause 6.2.9. L2 of 
TS 101 761-1 [1]. The priority rules for using granted DiL SCH is described in clause 6.2.2.2 of TS 101 761-1 [1]. The 
general MAC protocol described in clause 6.3 of TS 101 761-1 [1] applies to H/2-HDs. 

NOTE 2: If the CC itself is requesting resources for DiL UDCH, DiL RBCH, DiL DCCH, DiL UMCH, DiL 

UBCH, and, in case of discard messages, for DiL LCCH, these resources are requested internally and no 
DiL RR is transmitted. The message for requesting resources internally in the CC is 
implementation-specific and outside the scope of the present document. 

5.8 EC protocol for DM 
5.8.1 General 

The EC protocol is described in clause 6.2.2.2 of TS 101 761-1 [1]. The general aspects and the usage of EC in DM are 
described here. 

An additional Reed-Solomon based EEC mode is described in this document. This mode is optional for both CC and 
WT. 

DiL UDCHs for a certain connection shall either be sent in acknowledged mode, unacknowledged mode, or EEC mode. 
The negotiation during connection setup is defined by the corresponding DUC setup procedure. In case of the 
acknowledged mode, an implicit bi-directional DiL LCCH is set up. 

DiL UMCH shall either use the unacknowledged mode or the EEC mode. 

DiL DCCH on LCH and DiL RBCH on LCH shall use the unacknowledged mode. 

DiL UBCHs shall either be sent in repetition mode or unacknowledged mode. In the case where multiple convergence 
layers are supported, the DiL UBCHs may use different error control modes. In the case of the repetition mode, an 
implicit unidirectional DiL LCCH is set up corresponding to a DiL UBCH. 

The figures below illustrate the possible setups. In these examples, the terms "transmitter" and "receiver" mean that the 
data transmission under consideration is from the transmitter to the receiver, although e.g. a connection using the DiL 
UDCH may be bi-directional. The RR message control flow is not considered here. 

Eigure 3 illustrates the situation in the case of the acknowledged mode. A corresponding DiL LCCH is available which 
is used for ARQ feedback messages from the receiver to the transmitter and for discard messages from the transmitter to 
the receiver. 
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Figure 3: Illustration of the data and control flow in acknowledged mode 

Eigure 4 illustrates the situation in the case of the repetition mode. In this case, an implicit unidirectional DiL LCCH for 
discard messages from the transmitter to the receiver is available. 
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Figure 4: Illustration of the data and control flow in repetition mode 

Figure 5 illustrates the situation in the case of the unacknowledged mode. The data flows only from the transmitter to 
the receiver, no control data flow for ARQ feedback or discard messages is allowed. 
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Figure 5: Illustration of the data and control flow in unacknowledged mode 

Figure 6 illustrates the situation in the case of the FEC mode. The data flows only from the transmitter to the receiver, 
no control data flow for ARQ feedback or discard messages is allowed. 
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Figure 6: Illustration of the data and control flow in FEC mode 

5.8.2 Error Control (EC) protocol for the acknowledged mode 

The acknowledged mode uses an ARQ protocol and is described in clause 6.4.2 of TS 101 761-1 [1]. Most parts of the 
ARQ procedures of the transmitter and receiver are the same for CM and DM. Some special treatments for the direct 
link connections are summarized below. 



5.8.2.1 



Handling of Dynamic ARQ bandwidth allocation for DM 



The number of SCHs available for ARQ feedback messages may change from MAC frame to MAC frame. Therefore 
the number of bitmap blocks that can be signalled in a frame changes dynamically, as determined by the CC scheduler. 

In CM the destination of UL ARQ feedback is the CC and thus the CC scheduler. Therefore, it is possible to signal 
increased ARQ feedback capacity needs by setting the ABIR bit to 1 in the UL ARQ feedback message. In DM the 
destination of DiL ARQ feedback is the peer WT and not the CC scheduler. Therefore, the ABIR bit is not available for 
the direct Unk. 

NOTE: The calculation of the amount of extra SCH capacity granted by the scheduler in the CC is out of the 
scope of the present document. 
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5.8.2.2 Setting of the ARB in the RR for DiL 

In the case of a WT as a transmitter which is completely stopped (e.g. it has new LCHs to transmit but transmission is 
suspended by flow control or due to a stalled window), the WT may send a RR for DiL with #LCH = and ARB = 1 . 
Upon reception of such a RR for DiL, the CC scheduler should allocate appropriate resources for the receiving WT to 
transmit ARQ feedback messages. This allows the transmitter to inform the CC scheduler that it does not get sufficient 
feedback from the receiver. 

5.8.2.3 Receiver actions in case of insufficient ARQ feedback resources (informative) 

If the receiver detects that it does not get enough resources granted for ARQ feedback transmission, it may perform the 
following action (informative): 

• the receiver may request a more robust PHY mode for this specific connection, by setting a more robust PHY 
mode in a RR for this DiL connection. The #LCH and #SCH shall be set to zero, if no resources are to be 
requested. With a more robust PHY mode the number of reception errors may be decreased and thus the amount 
of ARQ feedback to signal negative acknowledgement. The amount of necessary CumAcks is not affected by the 
PHY mode setting. 

In DM a receiver cannot signal directly to the CC scheduler that the ARQ feedback resources are insufficient (see 
clause 5.8.2.1). 

5.8.2.4 Transmitter actions in case of insufficient ARQ feedback resources 
(informative) 

If the transmitter in DM is stopped, which means that within the transmitters window or Flow Control (FC) limitation, 
neither unacknowledged nor negatively acknowledged nor new LCHs are to be transmitted due to lack of ARQ 
feedback even if the transmitter buffer is not empty, the transmitter may set ARB in the DiL RR as described in 

clause 5.8.2.2. 

If the transmitter in DM is not stopped, it is not allowed to use ARB = 1 and #LCH = to signal to the CC scheduler 
that it wishes to have more frequent ARQ feedback. 

5.8.2.5 Scheduling of sufficient ARQ feedback resources (informative) 

The CC scheduler shall schedule sufficient resources for ARQ feedback. The definition of sufficient resources and the 
scheduling algorithm is outside the scope of the present document. Following informative text is given to indicate the 
parameters that influence the need for ARQ feedback: 

• The minimum necessary ARQ feedback resources are given by the number of transmitted (scheduled) UDCH 
and the negotiated ARQ window size. At least one LCCH for ARQ feedback has to be scheduled if as many 
UDCH have been scheduled as the size of the ARQ window. This minimum number is far too low for proper 
operation. 

• The average PDU error rate influences the number of necessary ARQ feedback messages. As this number is not 
known to the CC scheduler, an estimation has to be made. A worst-case assumption is 10 %, as if Link 
Adaptation in the Receiver works properly, the Receiver asks for a more robust PHY mode if the PDU error rate 
exceeds 10 %. Proper operation of the ARQ protocol with an average PDU error rate of more than 10 % is 
unlikely. 

• In order to limit the delay, the CC scheduler shall take into account the last time it has scheduled a DiL LCCH 
for ARQ feedback. The time between ARQ feedback signalling influences the total ARQ delay. 

• If the receiver requests a more robust PHY mode the CC scheduler may check whether it had scheduled 
sufficient resources for ARQ feedback. By scheduling more resources for ARQ feedback the Receiver may 
decide to ask for the former PHY mode again, if the reason for asking for a more robust PHY mode has been 
insufficient resources for ARQ feedback (see clause 5.8.2.2). 

In order to improve the system performance the CC scheduler shall spend spare resources for ARQ feedback, if 
possible. 
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5.8.3 EC protocol for the repetition and unacl^nowledged mode 

The EC protocol for the repetition mode and the unacknowledged mode is described in clauses 6.4.3 and 6.4.4 of 
TS 101 761-1 [1], respectively. 

There are no differences between DM and CM for the EC protocol for the repetition mode and the unacknowledged 
mode. 

5.8.4 EC protocol for the FEC mode 



5.8.4.1 



Principles 



When setting up a DiL UDCH or UMCH, an H/2-HD can determine if the DLC FEC mode shall be applied to this 
connection. When the FEC mode is selected, both acknowledged mode and unacknowledged mode are no longer 
possible for this connection. 

The DLC FEC scheme is based on a Reed-Solomon (RS) block code working on a multiple LCH-PDUs. For 8-bit 
symbols, the block length of the mother code shall be 2** - 1 = 255 bytes. To achieve an error correction capability of 
8 bytes per block, 16 bytes of redundancy shall be computed per block, leaving up to 239 bytes for protected data; 
hence, the mother code is a RS(255, 239) code. Out of these 239 bytes only 200 bytes shall be utilized by the DLC FEC, 
the rest is padding bytes which shall be only needed for computation but shall not be transmitted. The shortened code is 
referred to as a RS(216, 200) code. 

To suit the DLC FEC scheme, an additional UDCH message format is described which takes into account the specific 
information added by the FEC. DLC SDUs shall be concatenated in groups of 4 resulting in 200 bytes of protected data, 
as explained in clause 5.8.4.3. 

The performance of the FEC scheme is further enhanced by the insertion of a convolutional interleaver with a depth of 
12 DLC PDUs. 

NOTE: In DLC FEC mode, the packet error rate may be more affected by the error rate of RR and/or RG for the 
particular connection than by the residual error probability of the FEC scheme itself In this case, fixed 
slot allocation as presented in clause 6.6. 1 could be a means to avoid this limitation. 



5.8.4.2 



UDCH message format 



The non-ARQ mode is mainly intended to be used for the UDCH channel. The basic format of such a message is 
defined in the DLC basic TS (Table 1 and Table 2): 

Table 1 : Content of the UDCH with CRC 



Name 


Length (bits) 


Purpose 


PDU type 


2 


See Table 2 


SN 


10 


Sequence number (provided by EC function) 


Payload 


49,5 X 8 


Payload field, i.e. DLC SDU 


CRC 


24 


CRC-24 checksum 


Total: 


54x8 




Table 2: LCH Type field 


PDU type 


Purpose 


00 


Normal DLC PDU (carries UDCH, DCCH and RBCH) 


01 


Dummy LCH 


10 


Future use 


11 


Future use 



In case the DLC FEC is used, the UDCH message format is as shown in Table 3. 
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Table 3: Content of the UDCH with FEC 



Name 


Length (bits) 


Purpose 


PDU type 


2 


See Table 2 


Sync 


2 


Sync bits needed by FEC function 


Payload 


49,5 X 8 


Payload field (DLC SDU) 


FEC 


32 


One quarter of the RS redundancy 


Total: 


54x8 







8 7 


6 5 


4 


3 


2 


1 


1 


PDU type 


Sync 


MSB 








2 








3 


Payload 


4 


5 




Figure 7: UDCIH transfer syntax with FEC 



5.8.4.3 



RS word generation 



Every RS word is constructed from data of 4 LCH PDUs of 54 bytes. An RS word shall be obtained from 4 consecutive 
payload fields of 49,5 bytes each, originating from the upper layer, or generated by the DLC in case of dummy RS 
words. 

The PDU type shall be correctly set according to the Table 2, depending on the nature of the payload. If the payload is 
generated by the DLC as dummy, the PDU type for dummy LCH, which is 01, shall be used. 

In FEC mode, dummy LCH PDUs shall not be discarded, but shall be passed to the deinterleaver. 

The sync field is set according to Table 4. As can be seen, one sync field out of four is inverted from 00 to H . 

Table 4: LCH Sync field 



Sync field 


Purpose 


11 


PDU#1 


00 


PDU #2, #3 and #4 
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<r- 



50 bytes 




PDU-T S Payload PDU-T S Payload PDU-T S Payload PDU-T S Payload 



RS(216,200) 



^ 



216 bytes 



PDU-T 


S 


Payload 


FEC 




PDU-T 


S 


Payload 


FEC 




PDU-T 


S 


Payload 


FEC 




PDU-T 


S 


Payload 


FEC 



Figure 8: RS word generation 

The 4 blocks of 50 bytes, are concatenated to form a 200-byte block, where each 50 byte block consists of the 2-bit 
PDU type, the 2-bit Sync field in front of the 49,5 byte DLC SDU each, 39 zero bytes shall be padded before these 
200 bytes and the obtained 239 bytes are fed to the RS(255,239) Reed-Solomon code with the following properties: 

• Code Generator Polynomial: g(x) = (xh-|i")(xh-|i')... (xh-|i''), where |i = 02hex- 

• Field Generator Polynomial: p(x) = x** -i- x'' -i- x^ -i- x^ -i- 1 . 

The 39 zero bytes shall be discarded after computation of the RS code word and shall not be transmitted over the air 
interface. 

The redundancy of 16 bytes per RS(255, 239) is split into 4 packets of 4 bytes each which are inserted at the end of each 
DLC PDU according to Table 5. 

Table 5: Redundancy addressing within a RS word 



Redundancy bytes 


#1 


#2 


#3 


#4 


#5 


#6 


#7 


#8 


#9 


#10 


#11 


#12 


#13 


#14 


#15 


#16 


PDU 


#1 


#1 


#1 


#1 


#2 


#2 


#2 


#2 


#3 


#3 


#3 


#3 


#4 


#4 


#4 


#4 


Octet in the PDU 


#51 


#52 


#53 


#54 


#51 


#52 


#53 


#54 


#51 


#52 


#53 


#54 


#51 


#52 


#53 


#54 



5.8.4.4 



Dummy LCH PDU generation 



In the basic TS 101 761-1 [1], the DLC can insert dummy PDUs by setting the PDU type value to 01. The content of the 
dummy payload is not specified. 

However, in case the DLC FEC mode is used, the Sync field shall always be correctly set according to the rule given 
above, where every fourth Sync field is inverted from 00 to 11, see Table 4. The value of the other bits of the dummy 
PDUs is not specified. 

At connection release, the sender shall ensure that always a multiple of four PDUs are transmitted over the air. If this is 
not achievable by the user PDUs alone, the sender shall generate up to 3 dummy PDUs to complete the transmission of 
a multiple of 4 PDUs over the air. 

During the connection the sender may also generate as many dummy PDUs as necessary to fill multiple of 4 PDUs 
within one MAC frame. 
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5.8.4.5 



Interleaver and deinterleaver 



A Forney type convolutional interleaver with 3 branches is inserted after the RS output. The octets #1, #4,..., #52 of 
each LCH PDU shall be sent to branch #1, octets #2, #5,..., #53 to branch #2 and the other to branch #3. Explicitly, the 
rule for the interleaver DEMUX is that the octets #(3p+n), where < p < 17 and 1 < n < 3, shall be sent to branch #n. 
When a byte is sent to branch #n, the output from the interleaver MUX shall be the byte coming from the branch #n 
FIFO. The FIFO lengths shall be 0, 72, and 144 bytes, respectively. 

At the deinterleaver side, the FIFO lengths of branches #1, #2, #3 are 144, 72, and bytes, respectively. The octets #1, 
#4,..., #52 of each received LCH PDU shall be sent to branch #1, octets #2, #5,..., #53 to branch #2 and the other to 
branch #3. Explicitly, the rule for the deinterleaver DEMUX is that the octets #(3p+n), where < p < 17 and 1 < n < 3, 
shall be sent to branch #n. 
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Figure 9: Interleaver and deinterleaver 



5.8.4.6 



Interleaver/deinterleaver memories initialization 



When setting up a connection, the sender shall initialize the memories of the interleaver with relevant data, which once 
transmitted can be correctly decoded by the receiver. The sender shall generate one RS code word consisting of 
4 dummy 54-byte PDUs (called a dummy RS word). The payload (49,5 bytes) shall be set to zero, the PDU type to 01, 
and the sync field correctly set as specified in clause 5.8.4.4. The remaining 4 bytes are used as EEC redundancy. 

The payload of the dummy PDUs is set to zero, because they are generated locally in the transmitter and receiver, and 
shall have the same content. 

The 216 bytes obtained shall be then fed twice consecutively to the interleaver according to the interleaver rules, until 
both FIFOs are full. By doing so, the contents of the FIFOs of the interleaver are as follows, where byte #1 is the first 
byte of the first dummy PDU of the dummy RS word; 

• Branch #1: No FIFO. 

• Branch #2: 72 bytes: #215 #212 #209... #2. 

• Branch #3: 144 bytes: #216 #213 #210... #3 #216 #213 #210... #3. 

To save radio resources, no byte from the interleaver output shall be sent over the air during the FIFO initialization 
process, since the receiver deinterleaver can initialize its memory locally by using the same dummy RS words. With the 
same dummy RS word stored locally, the deinterleaver can achieve an equivalent initialization by taking into account 
the expected interleaver output and the deinterleaver rule. This results in the following FIFO contents in the 
deinterleaver branches after the equivalent initialization: 

• Branch #1: 144 bytes: #214#211 #208... #1 #214#211 #208... #1. 

• Branch #2: 72 bytes: #215 #212 #209... #2. 

• Branch #3: No FIFO. 
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Consequently, when a user PDU coming from the sender CL is input to the interleaver, the first outgoing byte at the 
deinterleaver output is byte #1 of the dummy RS word, and the n-th byte at the deinterleaver output is byte #n of the 
dummy RS word. Thus, the RS decoder works correctly. 

5.8.4.7 Connection termination 

In case a connection uses the DLC FEC mode, the end-to-end delay due to the interleaver-deinterleaver process equals 
8 PDUs. Hence, if a receiver has to decode the last PDU of a connection before the connection release, the sender shall 
take 2 actions: 

1) If a multiple of 4 PDUs is not achieved, add the missing number (1, 2 or 3) of dummy PDUs to complete a RS 
word. 

2) Purge the whole memories by generating two dummy RS words before releasing the connection. 

NOTE: The payload of the dummy PDUs used for completing the RS words and for purging can be of any values. 

Doing so, it is ensured that the last useful PDU is always read out of the deinterleaver, while the purging dummy RS 
words remain in the memories of the interleaver and the deinterleaver. 

5.9 Broadcast transmission 

The downhnk broadcast channels BCCH, FCCH, RFCH, RBCH and UBCH shall only be used by the acting CC. The 
BCCH is transmitted in the BCH and is identified by the occurrence of the BCH. The FCCH is transmitted in the FCH 
and is identified by the occurrence of the FCH. The RFCH is transmitted in the ACH and is identified by the occurrence 
of the ACH. The downlink RBCH is announced in the FCCH and is identified by MAC ID = and DLCC ID = in the 
case of the downlink. The downlink UBCH for a particular convergence layer is identified by the unique MAC ID that 
shall be assigned dynamically by the RLC (see TS 101 761-2 [2]) in the CC, taken from the MAC ID range 1 to 223, 
and DLCC ID = 63. 

The direct link broadcast channels RBCH and UBCH can be used by any H/2-HD to distribute control and user data, 
respectively, to all other H/2-HDs. The direct link RBCH is identified by the source MAC ID of the transmitting 
H/2-HD, destination MAC ID = 0, and DLCC ID = 0. The direct link UBCH for a particular convergence layer is 
identified by the unique destination MAC ID that shall be assigned dynamically by the RLC (see TS 101 761-2 [2]) in 
the CC, taken from the MAC ID range 1 to 223, the source MAC ID of the transmitting H/2-HD, and DLCC ID = 63. 

In both the CM and DM, the transmit power shall be adapted to the decoding quality of the farthest receiver. 

5.10 Encryption 

If encryption is used in the Home Environment, it shall be applied as described below. 

H/2-HDs shall encrypt UDCH, UMCH, UBCH and DCCH messages carried by LCHs using the DES algorithm. The 
RBCH is not encrypted (see TS 101 761-1 [1]). Encryption of SCHs is not possible. The implementation and use of the 
Triple DES is optional (TS 101 761-1 [1]). In TS 101 761-1 [1] and TS 101 761-2 [2] a unicast encryption key is used 
by every WT for encrypted UL/DL communication on LCHs with the CC. In the HE most of the communication links 
are DiLs between two WTs. On these DiLs the unicast keys cannot be used. In a subnet, all DiL LCHs sent by an 
H/2-HD therefore shall use one single encryption key. This key is thus a common key; it is called DM Common Key. 
The only case, where H/2-HDs do not communicate over DiLs, is the sending/reception of RLC messages to/from the 
CC. The concerned channels are UL DCCH, DL DCCH and DL RBCH. In contrast to TS 101 761-1 [1], in the HE DL 
DCCH is also used for point-to-multipoint communication. This implies the use of the Common Key in the case of DL 
DCCH. For this reason and for the sake of simplicity, H/2-HDs shall use the same DM Common Key also for UL 
DCCH and DL DCCH. Furthermore, this solution has the advantage that no unicast encryption keys need to be 
transferred in case of a CC Responsibility Handover. 

NOTE: DL RBCH remains un-encrypted in HE. 
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Since the DM Common Key shall be distributed to the WT in a secure way, it is nevertheless necessary that a unicast 
encryption key is generated by each WT during its association at the CC. For this purpose each H/2-HD shall 
implement the DBS algorithm, whereas the implementation of the Triple DBS is optional (TS 101 761-1 [1]). The 
choice of the encryption algorithm to be used for this purpose is negotiated between the CC and the WT during 
association (TS 101 761-2 [2]). 

During association the usage of the DM Common Key Distribution procedure shall be announced in the 
RLC-LINK-CAPABILITY-ACK message by setting the parameter DM-USB-COMMON-KBY to the value 
use-common-key. DM-USB-COMMON-KBY = no-common-key is not allowed for any H/2-HD. 

The CC shall generate a common key (see TS 101 761-2 [2]), define a Key Identifier for it, and call this key the 
DM Common Key. This key shall then be used for the encryption of all DiL as well as UL/DL DCCH LCHs of all 
H/2-HDs in the subnet. In case a low number of common keys is desirable, it is allowed to reuse the DM Common Key 
as DL Broadcast and DL Multicast Common Key. 

The DM Common Key Distribution shall be always carried out after the downlink and uplink unicast Encryption 
Startup procedure (see TS 101 761-2 [2]), after the authentication following the unicast encryption startup (association 
with authentication). In the DM Common Key Distribution procedure the CC shall send a message 
RLC_DM_COMMON_KBY_DISTR to the associating WT. The WT shall reply with the message 
RLC_DM_COMMON_KBY_DISTR_ACK. Authentication shall be carried out by all installed H/2-HDs, that have 
successfully completed the PIN and time-window protected authentication key exchange process in clause 6.9. 

The message RLC_DM_COMMON_KBY_DISTR defines the encryption algorithm that is used and contains the 
Common Key Identifier and the DM Common Key. Since the message is encrypted with the downlink/uplink unicast 
key, the DM Common Key cannot be read by an eavesdropper. 

The response message RLC_DM_COMMON_KBY_DISTR_ACK contains the descriptor of the encryption algorithm 
as a confirmation and a hash sum of the Common Key Identifier and the DM Common Key. The hash sum consists of 
the MD5 sum on the concatenation of the Common Key Identifier and the DM Common Key. 

The unicast encryption key shall be used to encrypt all sent messages during the association procedure, but in the HB it 
shall be never used after the association procedure has ended. Once associated, an H/2-HD shall always use the 
Common Key for the encryption of (DiL and UL/DL DCCH) LCHs. 

Once the DM Common Key is received by an H/2-HD, it shall use the encryption and decryption procedure in 
clause 6.7.4 of TS 101 761-1 [1] to encrypt and decrypt LCHs to and from other H/2-HDs. The seed sent periodically 
by the CC in downlink RBCH is used to support the generation of the Initialization Vector (IV) in each WT. All 
H/2-HDs have a seed generator, which cycles stepwise in the same way to produce non-repeating seeds (before it 
wraps) for each MAC frame. The seed generator of a WT shall be reset by the newly received seed from the CC, if its 
decoding was successful (TS 101 761-1 [1]). A new IV is used for each DiL LCH. The IV is a function of the locally 
generated seed and the 12 LSBs of the start pointer value in the FCCH IB for that particular connection. This ensures 
the synchronization of the encryption and decryption processes for each connection, although only a single DM 
Common Key is used for all encrypted LCHs and all H/2-HDs. 

The DL Broadcast and DL Multicast Common Keys described in TS 101 761-2 [2] shall be distributed after the 
association. The distribution of these keys is protected against eavesdropping by encryption with the DM Common Key 
in case of an H/2-HD and by encryption with the unicast key in case of a Non HB-compliant Device. Only in case that 
one or multiple Non HB-compliant Devices participate in the network, there may also be DL Broadcast or DL Multicast 
groups in which an H/2-HD wants to participate, too. While the distribution mechanism of the DM Common Key 
differs from the distribution of DL Multicast and DL Broadcast Common Keys, the refresh mechanism is the same for 
all common keys. 

As Non HB-compliant Devices shall be also supported by the CC of a HB subnet, the CC has the task to differentiate 
between H/2-HDs and Non HB-compliant Devices. The CC shall be aware that a Non HB-compliant Device will 
encrypt UL DCCH and UL UDCH with its unicast encryption key. The CC shall encrypt all messages directed to a Non 
HB-compliant Device and carried on a DL DCCH or DL UDCH with the unicast encryption key of that WT. DL UBCH 
and DL UMCH messages are encrypted with the DL Broadcast and DL Multicast Common Key, respectively. On the 
other hand, the CC shall be aware that an H/2-HD will encrypt all UL DCCH, DiL DCCH and DiL UDCH messages 
with the DM Common Key. Table 6 gives an overview over the use of the different encryption keys for the two 
different device types. A dash in a field indicates that the channel used by one device type is not used by the other 
device type. 
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Table 6: Encryption of logical channels for H/2-HDs and Non HE-compliant Devices 



Sender 


H/2-HD 


Key used by H/2-HD 


Non HE-compliant 
Device 


Key used by Non l-IE- 
compliant Device 


CC 


DL DCCH 


DIVI Common Key 


DL DCCH 


UnlcastKeyofWT 


cc 


- 


- 


DLUDCH 


Unicast Key of WT 


CC 


DL RBCH 


Not encrypted 


DL RBCH 


Not encrypted 


cc 


- 


- 


DL UBCH 


DL Broadcast CK 


cc 


- 


- 


DLUMCH 


DL Multicast CK 


WT 


UL DCCH 


DM Common Key 


UL DCCH 


UnlcastKeyofWT 


WT 


- 


- 


ULUDCH 


Unicast Key of WT 


H/2-HD 


DIL RBCH 


DM Common Key 


- 


- 


H/2-HD 


DiL UBCH 


DM Common Key 


- 


- 


H/2-HD 


DILUMCH 


DM Common Key 


- 


- 


H/2-HD 


DiL DCCH 


DM Common Key 


- 


- 


H/2-HD 


DiL UDCH 


DM Common Key 


- 


- 


NOTE 1 : H/2-HD includes both WT and CC. 

NOTE 2: If an H/2-HD is to communicate with a Non HE-compliant Device, this H/2-HD shall operate in CM with respect 
to the connections to and from the Non HE-compliant Device. 





6 Services supported by the Radio Link Control 

sublayer 

6.1 General (informative) 

The radio link control sublayer supports: 

• Association Control Function (ACF) including Encryption, Authentication and Key Management. Additionally 
to these basic functions the Home Environment specification (the present document) supports Multiple 
Convergence Layers. 

• Radio Resource Control (RRC): the "Dynamic Frequency Selection", the "MX Absence" and the "Power Saving 
functions" of the RRC are also required for Home Environment whereas the cellular "Handover" is an optional 
functionality for H/2 home devices. Additional functions in the home environment are the Dynamic CC 
Selection and the CC Responsibility Handover described in clauses 6.7 and 6.8. The Power Control and the Link 
Adaptation functions for the CM are described in TS 101 761-1 [1]. The corresponding functions for the DM are 
specified in the present document. 

• DLC User Connection Control (DUCC): the DUCC contains functions for the establishment and the 
modification both of unicast and multicast connections. The DUCC basic functions in TS 101 761-2 [2] include 
DUCC for the direct link unicast and DiL multicast without QoS negotiation. The DiL multicast with QoS 
negotiation is specified in clause 6.6.2 of the present document. 

6.1 .1 Basic RLC functions applied 

The following concepts of the RLC basic functions TS 101 761-2 [2] have been adopted: 

• usage of DLC logical and transport channels for RLC messages; 

• transfer Syntax of RLC (except DiL and DL multicast DCCH); 

• sequencing of RLC messages; 

• ASN. 1 definition of the RLC PDUs; 

• timers and repetitions of RLC messages. 
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6.1.1.1 DLC User Connection Control 

The DUCC contains functions for the estabhshment, modification and release of unicast, muhicast and broadcast 
connections. Furthermore the DUCC for direct link unicast is described in TS 101 761-2 [2]. 

6.1 .1 .2 Radio Resource Control 

Dynamic Frequency Selection 

The Dynamic Frequency Selection (DFS) is applied in the HE in the way it is supported by the TS 101 761-2 [2]. The 
DFS avoids the interference of other devices using the same frequency band that may arise from neighbouring H/2 
networks using the same frequency or Non HE-compliant Devices on the frequency band. The H/2 DFS scheme is 
centralized to CCs. Every CC collects measurement results and chooses the operating frequency independently of other 
CCs. 

MX Absence 

The MT Absence function is for WT maintenance purposes (scanning channels, etc.). The MT Absence in CM is 
defined in TS 101 761-2 [2]. The MT Absence in DM does not differ from the procedure in CM. In DM, the user 
packets to be transmitted to a WT in the absence state are queued in the transmitting WT, not in the CC. 

6.1 .2 Changed RLC functions 

6.1.2.1 Association Control Function 

In HE, the CC is determined as a result of the CC Selection process. Its role is handed over to another CC-capable 
H/2-HD after a successful CC responsibility handover. A HE-compliant H/2-HD only tries to associate with the CC 
whose NET-ID matches that stored in the H/2-HD, see clause 6.9. If more than one such CC is detectable, the H/2-HD 
may first try to associate with the CC with the best receive quality. Since the NET-ID is just a random number, it is 
possible that the same NET-ID value is used by a nearby non HE-compliant CC. Therefore, the HE-compliant H/2-HD 
may abort the association process with a CC, as soon as it detects that this CC is not HE-compliant. Re-association with 
this Non HE-compliant CC is optional, if the HE-compliant H/2-HD cannot find any other HE-compliant CC with the 
same NET-ID, and if it is unable or not willing to become the CC of the HE-compliant network. 

NOTE 1: A manufacturer can implement on an H/2-HD different usage profiles. By selecting a Non HE-compliant 
usage profile, the user can configure an H/2-HD as a Non HE-compliant device to be preferably 
associated with a non HE-compliant CC. 

NOTE 2: A H/2-HD acting as CC may allow a Non HE-compliant Device to associate with the network. In this 
case, all H/2-HDs having communications with that Non HE-compliant Device operate in CM with 
respect to all connections to and from that Non HE-compliant Device. 

Terminal association for multiple CLs 

After the RBCH Association message transfer the list of CL-IDs is processed by the WT. The WT aborts the association 
process if there are no corresponding CLs supported. If several CLs are supported both by the CC and the WT, the WT 
selects CL IDs according to a set of rules that are defined in clause 6.2. The WT transmits the selected CL-ID-list to the 
CC in the RLC_LINK_CAP ABILITY message which is sent after the MAC ID assignment. 

6.1 .2.2 Radio Resource Control 

Power Saving 

The Power Saving functions are initiated by the WT with the purpose of entering or leaving low consumption modes 
and controlling the power of the transmitter. Direct link connections addressed to a WT that is in a power saving state 
should not be scheduled by the CC. The CC should wake up the sleeping WT, when detecting another WT having 
pending data for this sleeping WT. 
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6.1 .3 RLC messages, parameter settings 

6.1.3.1 Association Control Function 

The parameters exchanged during association and being relevant to H/2-HDs are described below: 

direct-mode-cap: The value of the direct-mode-cap field is set to 1 ("dm-capabilities") for all H/2-HDs. 

(message: RLC_LINK_CAPABILITY). 

cl-vid-list: H/2-HD may support more than one CLs. The IDs of these CLs are then included in this 

CL-ID-List. (messages: RLC_RBCH_ASSOCIATION, RLC_LINK_CAPABILITY). 

support-fsa: FSA is supported, the Support-FSA field is set to the value 1 ("support-fsa"). (message: 

RLC_LINK_CAPABILITY,RLC_LINK_CAPABILITY_ACK). 

cc-ho-cap: A CC-capable H/2-HD supporting CC responsibility handover sets this parameter field to 

cc-ho-supported. (message: RLC_LINK_CAPABILITY). 

dm-use-common-key: This parameter field is used to indicate if the DM Common Key distribution procedure is 

performed. It is then set to the value "use-common-key", (message: 
RLC_LINK_CAPABILITY). 

dm-attributes: The parameter field dil-power-control is set to dil-dynamic-pc, the parameter fields 

rx-arq-win-size and tx-arq-win-size are set to the supported ARQ window size, (message: 
RLC_LINK_CAPABILITY,RLC_LINK_CAPABILITY_ACK). 

6.1 .3.2 DLC User Connection Control 

The following parameters contained in the setup/modify messages for DiL UDCH and DiL UMCH shall be set as 
follows: 

cl-id: This parameter is set to the ID of the CL instance that sets up or modifies a DiL UDCH or 

DiL UMCH. 

NOTE: CL-ID is also used by the join and leave procedures for DiL UBCH or DiL UMCH. 

allocation-type: The allocation-type parameter in duc-descr describes the type of connection: basic, fca, or 

fsa. 

fee-used: The fee-used flag is set for each DiL UDCH or DiL UMCH that uses FEC mode. 

fee: The fee field defines the coder type and the interleaver type of the applied FEC. 

6.1 .4 New RLC functionality 

CC Selection, CC Responsibility Handover 

Because of the ad hoc network topology, additional functions like the CC selection procedure and the CC 
Responsibility Handover procedure are introduced in clauses 6.7 and 6.8. Direct Link related Functions 

DiL Link Adaptation, DiL Power Control, and Link Quality Calibration, are specified in clauses 6.3, 6.4, and 6.5. 

The DiL UMCH setup/modify/release is specified in clause 6.6.2, and the use of DiL UBCH is specified in clause 5.9. 

Authentication Key Exchange 

The Key Exchange with special reference to direct link requirements is specified in clause 6.9. 

Fixed Slot Allocation 

The fsa-descr field in the duc-descr parameter list of TS 101 761-2 [2] enables the establishment of an FSA connection, 
which is further elaborated in the present document. The FSA enables the reservation of slots at fixed positions in the 
MAC Frame which cannot be changed with normal RGs. 
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6.2 Terminal association for multiple convergence layers 
(OCC/OWT) 

In the HE multiple active CLs may make use of multiple CLs, since WTs may be connected to different types of fixed 
networks, for example IEEE 1394 and Ethernet. 

Support of multiple convergence layers in parallel is optional. If this feature is supported, it shall be performed as 
described below. 

In this case, the terminal association is done in several steps. In the RBCH Association procedure the CC shall inform 
the WT about the CLs supported in parallel by the CC, using the cl-vid-list parameter. During the link capability 
procedure, the WT informs the CC about the CLs it wants to associate with, also using a cl-vid-list. The WT's cl-vid-Ust 
shall be a sub-set of the cl-vid-list sent by the CC. If none of the CL IDs sent in RBCH association message is supported 
by the WT, the WT shall not continue with the association. 

In case of successful negotiation of CL-IDs, the info transfer procedure (see TS 101 761-2 [2]) shall be subsequently 
performed between the WT and the CC for each selected CL-ID. Per CL-ID one info transfer is performed. The format 
of the INFO_PDU is described in TS 101 761-2 [2]. After successful association of the CLs, the CL-specific C-SAP(s) 
and U-SAP(s) are created for the individual CL-IDs. During DiL UDCH or DiL UMCH setup the CL-ID contained in 
the messages identifies the C-S AP of the addressed CL. After the setup of a DIL UDCH or DiL UMCH, the DUC-ID 
implicitly identifies the U-SAP of the addressed CL. 

6.3 Link adaptation in Direct Link phase (OCC/OWT) 

In unicast DiL communication only the receiver is allowed to recommend a new PHY mode based upon the packet 
decoding quality at any time. In this case the receiver shall set the PHY mode LCH and PHY mode SCH parameters in 
RR for DiL to the proposed new PHY mode, see clause 6.2.9.1 of TS 101 761-1 [1]. The parameters #SCH and #LCH 
shall be set to zero. 

NOTE: In contrast to a RR for DiL used for unicast link adaptation (#LCH = #SCH = 0), which is issued by a 
receiver, the RR for DiL with #LCH > and/or #SCH > can only be sent by the transmitter of a DiL 
connection to request LCH(s) and/or SCH(s). 

In multicast/broadcast DiL communication, link adaptation shall only be performed in conjunction with transmit power 
control in clause 6.4.2. Here, a new PHY mode shall only be recommended by the sender of a multicast connection, 
which is defined uniquely by the sender MAC -ID and the multicast MAC-ID. The sender of a multicast connection may 
propose a more robust PHY mode, if the transmit power for this connection has reached the upper boundary, and at 
least one of its receivers is suggesting a higher transmit power. It can propose a less robust PHY mode, if the transmit 
power for this connection has reached the lower boundary, and all of its receivers are suggesting a lower transmit 
power. The sender of the multicast connection shall use a RR for DiL to recommend the new PHY mode for LCH 
and/or SCH. It shall set #LCH and/or #SCH to zero, if no real resources are requested by this RR. 

For both direct link unicast and multicast, the CC shall not change the PHY mode of a DiL connection without 
recommendation from the involved WTs. 

6.4 Power control in Direct Link phase (OCC/OWT) 

Transmit power control, in direct link phase, enables the transmitting WT to always set its transmit power level 
appropriately, to provide acceptable reception quality at the receiving WT. This is determined according to the explicit 
recommendation from the receiver to the transmitter, to increase or decrease its power level by a certain value (dB). The 
criteria the receiver uses to determine this value is implementation specific. 

NOTE: The receiving WT might use received signal strength (RSS) or the BER of received data as a criteria for 
reception quality. 

If transmit power control is supported, it shall be performed for unicast and multicast/broadcast connections in direct 
link as described below. 
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For the purpose of power control in unicast and multicast/broadcast, the message RLC_DM_POWER_CONTROL is 
used as described below: Since unicast and multicast/broadcast PDUs from the same sender are not necessarily received 
in one PDU train, transmit power control is performed separately. A connection type field dm-duc-type in 
RLC_DM_POWER_CONTROL indicates whether the recommendation concerns unicast or multicast/broadcast PDUs 
originating from the same sender. 

RLC_DM_POWER_CONTROL messages shall be always transmitted using the most robust PHY mode. The transmit 
power level may vary, and is specified below. 

6.4.1 Direct Link unicast power control 

If transmit power control is supported, it shall be performed for each unicast DUC in DiL, for both simplex and duplex 
connections. Two WTs that have several DUCs, using different PHY modes, would usually require different transmit 
power levels. However, since PDUs belonging to different DUCs which are sent from one WT to a peer WT in one 
MAC frame, are transmitted in a train, the same transmit power level shall be used for all PDUs in the train. The 
transmit power level is set to satisfy the connection with the worst reception quality (i.e. less robust PHY mode). This is 
provided by the receiver's explicit recommendation. 

In unicast, the power control scheme in direct link phase is performed as follows: 

1) connectivity check: performed during the first DiL DUC Setup between a WT pair; 

2) power update: performed after each DiL DUC Setup involving the same WT pair, and during the lifetime of 
their unicast connections. 

During the first DiL DUC Setup, the peer WTs exchange power control messages, in order to check if a direct radio link 
is possible. After the first connection setup is successfully completed, and during the lifetime of the connection, power 
update is dynamically performed, to inform the sender about appropriate transmit power level. Power update can also be 
performed after a further DiL DUC setup between the same WT pair, to take into account different power requirements 
for different PHY modes. 

6.4.1.1 Connectivity check 

Connectivity check is performed only for the first DiL DUC between two WTs using RLC_DM_POWER_CONTROL 
messages. During the setup of the first unicast DiL DUC (see TS 101 761-2 [2]), the CC enables both WTs to perform 
connectivity check by granting each WT at least one DiL DCCH to transmit its power control message, using a SCH. 
The CC itself can be one of the WTs. The CC shall send the RGs to both WTs, after the second 

RLC_DM_CONNECT_ACK message (to WT2), and before the first RLC_DM_CONNECT_COMPLETE message (to 
WTl), have been sent. This is shown in the following MSCs for both CC and WT initiated DUC setup. The CC may 
grant resources for connectivity check several times during this period. All these granted DiL DCCH SCHs to this WT 
pair shall be used for connectivity checking. All RLC_DM_POWER_CONTROL messages sent for connectivity check 
shall be transmitted at maximum allowed power level. 
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WTl 



cc 



WT2 



RLC DM SETUP 



RLC_DM_CONNECT 



RLC DM CONNECT ACK 



RLC_DM_SETUP 



RLC DM CONNECT 



RLC_DM_CONNECT_ACK 



CC grants DCCH SCHs for WTl and WT2, implicit power control trigger 
WTl transmits RLC power control message, WT2 measures reception quality 
WT2 transmits RLC power control message, WTl measures reception quality 



RLC_DM_CONNECT_COMPLETE 



RLC_DM_CONNECT_COMPLETE-ACK 

If connectivity check was 
successful! 



RLC_DM_CONNECT_COMPLETE 



RLC_DM„CONNECT_COMPLETE-ACK 

If connectivity check was 
successful! 



DUG established 



Figure 10: Direct Linl< Setup procedure - CC initiated 
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CC grants DCCH SCHs for WTl and WT2, implicit power control trigger 
WTl transmits RLC power control message, WT2 measures reception quality 
WT2 transmits RLC power control message, WTl measures reception quality 



RLC_DM_CONNECT_COMPLETE 



RLC_DM_CONNECT_COMPLETE_ACK 

If connectivity check was 
successful! 



RLC_DM_CONNECT_COMPLETE 



RLC_DM„CONNECT_COMPLETE_ACK 

If connectivity check was 
successful! 



DUG established 



Figure 11 : Direct Linl< Setup procedure - WT initiated 



RLC-DM-POWER_CONTROL-ARG::= SEQUENCE { 



ric-pdu-type 
extension-type 
dm -due-type 
wt-tx-level 
adjust-tx 



RLC-HE-SCH-PDU-TYPE, 

EXTENSION-TYPE, 

DM-DUC-TYPE, 

TX-LEVEL 

ADJUST-TX } 



The RGs are considered as an implicit trigger for connectivity check. No RR shall be generated by the WTs. On 
reception of such an RG, each WT transmits RLC_DM_POWER_CONTROL message to the peer WT, using the 
maximum allowed transmit power level for the frequency band of operation. Each WT measures then the reception 
quality (e.g. using RSS, BER, etc) of the RLC_DM_POWER_CONTROL message from the peer WT. 
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Either WT shall abort the DiL DUC connection setup in the following cases: 

• It is not granted at least one DiL DCCH SCH, or cannot successfully decode at least one corresponding RG, 
before receiving the RLC_DM_CONNECT_COMPLETE message from the CC. 

• It could not receive the RLC_DM_POWER_CONTROL message, or the reception quality was not acceptable. 

In order to reject the DiL DUC Setup the WT shall send RLC_DM_RELEASE message and continue with the DiL 
Release procedure. 

Either WT shall only acknowledge the RLC_DM_CONNECT_COMPLETE message from the CC with 
RLC_DM_CONNECT_COMPLETE_ACK, after it has successfully decoded at least one 
RLC_DM_POWER_CONTROL message from the peer WT, and it has sent at least one 
RLC_DM_POWER_CONTROL message to the peer WT. 

In case both WTs successfully acknowledged the RLC_DM_CONNECT_COMPLETE from the CC, the connectivity 
check is considered successful, and the connection setup is successfully completed. 

6.4.1.2 Power update 

As long as there is at least one unicast connection between a WT pair, power update is performed whenever it is 
necessary. After each further unicast connection setup or release, either WT should consider performing power update, 
to ensure always satisfying the connection with worst reception quality. 

Each WT continuously monitors the received signal quality of all its unicast connections with the peer WT. If a WT 
detects a worsening or an improvement of the received signal strength or another reception quality criterion 
(implementation specific) above an acceptable threshold, it should request a DiL DCCH SCH to transmit a 
RLC_DM_POWER_CONTROL message. The message contains an explicit recommendation to the peer WT to adjust 
its transmit power level for unicast traffic appropriately. For the RLC_DM_POWER_CONTROL message transfer the 
WT shall use the most robust PHY mode. If this message is transmitted together with other PDUs, the regulated Power 
level, otherwise the maximum transmit power level, shall be used for the unicast transmission. 

Even though the radio channel can be considered symmetric in most of the cases, it is recommended that a transmitting 
WTl only adapts its power level based on explicit recommendation from the receiving WT2. WTl should not change 
its transmit power level based on the change of its own reception quality for WT2. 

Latest, two frames after either WT has successfully decoded the received RLC_DM_POWER_CONTROL message 
with explicit recommendation, it shall start to transmit all its direct link unicast traffic to the peer WT, using the 
adjusted power level. 

The power control scheme in direct mode should not react on burst changes of the radio channel, rather on persistent 
changes. The exact algorithm is implementation specific. 

In case the PHY mode is changed during a connection, the WTs might also readjust the transmit power levels 
accordingly. 

In addition to the dm-duc-type field and recommendation for power control, the RLC_DM_POWER_CONTROL 
message also contains the current transmit power level of the sender of this message, for all its unicast connections with 
the receiving WT. Thus, the receiving WT recognizes whether the transmitter has reached the lower or upper transmit 
power limit in the frequency band of operation. In this case, the peer WTs might initiate a change of PHY mode for link 
adaptation, see clause 6.3. 

If a WT does not react to a recommendation from its peer WT after two frames, the originator of the recommendation 
shall retransmit its RLC_DM_POWER_CONTROL message. 

In case the receiving WT can no more successfully decode the received user data, it shall transmit its 
RLC_DM_POWER_CONTROL message at the maximum transmit power level, informing the sender to increase its 
transmit power level to the recommended value. If the receiver is still not able to successfully decode received data, it 
might trigger a PHY mode change for link adaptation, before it releases the connection. 

RLC_DM_POWER_CONTROL messages can be exchanged anytime by just requesting SCH for DiL DCCH, as long 
as there is at least one connection between the WT pair. 
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6.4.2 Direct Link multicast/broadcast power control 

If transmit power control is supported, it shall be performed for multicast and broadcast connections as described below 
(quasi static transmit power control scheme). The sender shall start transmission of the first multicast/broadcast 
connection, at 3 dB below the maximum allowed transmit power level for the centre frequency where it is operating. No 
connectivity check is performed in DiL broadcast or multicast connections (both with and without connection setup). 

After multicast/broadcast connection has started (corresponding RGs in FCH), each receiving WT shall send its 
RLC_DM_POWER_CONTROL message to the multicast/broadcast sender, latest within a timer 
T_mc_dm_power_control. A receiving WT that could successfully decode the corresponding user data informs the 
multicast/broadcast sender to decrease its transmit power level by a certain value. A receiving WT that could not 
successfully decode the user data requests the multicast/broadcast sender to increase its transmit power level 
appropriately. The multicast/broadcast sender shall adjust its transmit power level, in order to satisfy the receiver with 
the worst reception quality, i.e. which recommended highest increase or lowest decrease of power level. The sender 
shall always ensure that it is compliant with the maximum allowed transmitted power level for the centre frequency 
where it is operating. 

Similar to unicast, the sender shall always use the same transmit power level for all its active multicast and broadcast 
connections, even if different multicast groups are target. The receiving WTs should therefore determine the required 
transmit power adjustment for a certain multicast/broadcast sender, based on the multicast or broadcast connection with 
the worst reception quality. 

During the lifetime of all multicast/broadcast connections from the same sender, each receiving WT shall send its 
RLC_DM_POWER_CONTROL message to the sender whenever necessary, but not less than once every 
T_mc_dm_power_control. The sender should adjust its transmit power level, if it notices that all receiving devices have 
a persistently acceptable reception quality according to their RLC_DM_POWER_CONTROL messages. 
Recommendations from multicast/broadcast receivers to increase the transmit power level shall be applied latest two 
frames after reception of the corresponding RLC_DM_POWER_CONTROL message. The multicast/broadcast sender 
shall however not reduce its transmit power level by more than 3 dB within T_mc_dm_power_control. This shall ensure 
that the sender does not react to burst characteristics of the radio channel. 

Since a new multicast/broadcast connection might require higher transmit power level than already active ones (if it 
uses different PHY mode, or it targets different multicast receivers), each new multicast/broadcast connection shall be 
started at 3 dB below the maximum allowed transmit power level, or the currently used multicast/broadcast power level 
if it is higher. Consequently, latest when a new multicast/broadcast connection is started, the sender shall have increased 
the power level of all its active multicast/broadcast connections, if it was originally less then 3 dB below the maximum 
power. If the power level of active connections already exceeds this level, the same level shall be used for the new 
connection as well. After the new multicast/broadcast connection is started, the appropriate transmit power level is 
determined based on the receiver's recommendations. 

NOTE: The sender may steadily perform the increase of power level for example during multicast connection 

setup. 

RLC_DM_POWER_CONTROL messages for direct link multicast/broadcast power control may be transmitted 
together with unicast traffic to the multicast sender. In this case, this message may be transmitted at regulated transmit 
power level for unicast traffic. Otherwise, the RLC_DM_POWER_CONTROL message shall be transmitted using the 
maximum transmit power level. Thus it can be assumed that the sender can successfully decode the messages from 
those receivers, where direct link connection is possible. The sender may initiate link adaptation (see clause 6.3), if the 
transmit power for its multicast/broadcast connections has reached the upper (lower) boundary, and at least one (all) of 
its receivers is suggesting a higher (lower) transmit power. 

A multicast/broadcast receiver may retransmit its RLC_DM_POWER_CONTROL message several times to request the 
sender increase its power level, if the sender does not satisfy this request within two frames. The receiver may leave the 
multicast/broadcast group if the reception quality is still not acceptable. 

A new WT that joins a multicast/broadcast group, first checks if a connection is active (corresponding RGs in FCH). 
Depending on the reception quality of all active multicast/broadcast connections from the same sender, the new WT 
shall send its RLC_DM_POWER_CONTROL message with appropriate recommendation, latest within 
T_mc_dm_power_control. 
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6.5 Link quality calibration for DIVI operation (OCC/OWT) 

The link quality calibration aims at creating a map of the network, which describes the quality of the radio link between 
each WT pair, including the CC. The link quality map is required by H/2-HDs for several reasons, for example CC 
responsibility handover, future support of hidden nodes, loop detection in 1394 networks, etc. 

If link quality calibration is supported, it shall be performed as described below. 

6.5.1 Principles of calibration 

The calibration procedure consists of two phases: measurement phase and reporting phase. It is always triggered by the 
CC, and it is started in two cases: 

• High Priority Calibration 

When a new WT joins the network, the CC shall trigger a calibration procedure with high priority. The CC 
allocates resources for the measurement and reporting phases as described in the following clauses. 

• Low Priority Calibration 

To keep the link quality map of the network up to date, the CC shall trigger low priority calibrations, if spare 
resources are available. It is up to the CC to determine the frequency of low priority calibrations. Depending on 
the mobility of the WTs, the update interval might vary from 100 ms to a few minutes. The algorithm to 
determine the frequency of calibration is an implementation specific issue. 

NOTE 1 : If the CC is to take a decision based on the link quality map, such as to select the best CC-candidate, it 
should be aware that an RSS2 value in the link quality map could be outdated. 

The triggers for both measurement and reporting phases have a lifetime of T_trigger_lifetime each. Within the lifetime 
of a measurement or report trigger the CC shall send out neither a new measurement trigger, nor a new report trigger. 
The lifetime of a measurement or report trigger begins with the start of the next MAC frame following the MAC-frame 
that contains that trigger PDU. 

Since link quality calibration is always triggered by the CC, only Resource Grant messages are required (no RR for 
calibration). Resource grants for measurement and report PDUs are announced in FCCH, using the RG IE for DiL 
RBCH. The CC shall act as a WT to use the measurement PDUs during the measurement phase. 

All measurement, report and trigger messages shall be transmitted using the most robust PHY mode, and the maximum 
transmit power level. Further, it is suggested that the entire link quality calibration is always performed using 
omni-directional antennas, at both transmitter and receiver sides, without support of antenna diversity. This enables a 
fast calibration of the network. A more accurate calibration of the network, using sectorized antennas, requires very 
extensive measurements. 

NOTE 2: The omni-directional antenna can be implemented using existing sectorized antennas. 

The CC may wake up a sleeping WT (TS 101 761-2 [2]) to perform measurement or report. 

The granted calibration measurement and report DiL RBCH resources may become ambiguous for a WT, if it had not 
received the corresponding trigger within the last T_trigger_lifetime and it had not sent a RR for the same DiL RBCH 
resources before the grant. If a WT cannot unambiguously identify the purpose of a granted DiL RBCH SCH or DiL 
RBCH LCH, it shall send a dummy DiL RBCH SCH or LCH PDU with all payload bits set to zero. 

NOTE 3: A WT may use granted DiL RBCH resources for purposes other than calibration, if it had not received the 
corresponding calibration trigger within the last T_trigger_lifetime and it had sent a RR for the same DiL 
RBCH resources before the grant. 

The CC maintains the resulting link quality map of the network, and may be requested by any WT to broadcast its 
contents as described in clause 6.5.4. 
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6.5.2 Measurement phase 



The measurement phase is started by the caHbration-measurement trigger broadcast by the CC. The hfetime of the 
measurement trigger is T_trigger_Hfetime, within which a triggered WTl is granted a SCH for DiL RBCH to be sent as 
measurement PDU. This PDU shall be received by other WTs to determine the quality of their links to WTl. The 
measurement phase for WTl is completed after the trigger has expired. 



6.5.2.1 



Calibration-measurement trigger 



The CC shall trigger the start of the measurement phase by broadcasting the 

RLC_CALIBRATION_MEASUREMENT_TRIGGER message using a downlink RBCH SCH. Selective triggering 
shall be enabled for simultaneous calibration measurements and calibration reporting from different WTs (Figure 12). 
The trigger type indicates whether all WTs will be requested to perform calibration measurement, or only a set of 
selected WTs. In case only a set of WTs (up to three) is triggered, the corresponding MAC-ID list shall be included in 
the trigger message. 



MSC Calibration_Measurement_T rigger 


WT_ENV WT_RLC CC_RLC CC_ENV 


RRC_cali 


RLC_CALIBRATIOh 
)ration_measurement_Trigger_lnd 


RRC_calib 
LIVl EASUREIVI ENT_TRIGGER 


'ation_l\/leasurement_Trigger_Req 




(mac-id (broadcast), 

trigger-type, 

mac-ids) 


(trigger-type, 
mac-ids) 








DLRBCH 






(mac-id (broadcast), 

trigger-type, 

mac-id -list) 









Figure 12: MSC for RLC_CALIBRATION_MEASUREMENT_TRIGGER 

The RLC_CALIBRATION_MEASUREMENT_TRIGGER message shall be transmitted using the most robust PHY 
mode. 

After calibration measurement trigger, the CC shall grant DiL RBCH resources to all, or a set of WTs to transmit 
calibration measurement PDUs in direct link. Only DiL RBCH SCHs granted within the lifetime of the measurement 
trigger shall be regarded as measurement PDUs. 

Table 7: RLC-CALIBRATION-MEASUREMENT-TRIGGER 



RLC-CALIBRATION-MEASUREMENT-TRIGGER-ARG: 


:= SEQUENCE { 


ric-pdu-type RLC-HE-SCH-PDU-TYPE, 




extension-type EXTENSION-TYPE, 




trigger-type TRIGGER-TYPE, 




mac-ids IVIAC-IDS} 
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6.5.2.2 



Calibration measurement 



After reception of a (network-wide or selective) calibration-measurement trigger message from the CC, a WT that is 
granted a SCH in DiL RBCH as transmitter shall broadcast a RLC_CALIBRATION_MEASUREMENT message 
during direct Hnk phase (Figure 13). It shall set the source MAC -ID of this DiL RBCH to its own MAC -ID. 

A WT, which is granted a DiL RBCH SCH without having received a measurement trigger message from the CC 
during the last T_trigger_lifetime (the measurement trigger lifetime) shall not use this DiL RBCH SCH for calibration 
measurement. It may use this DiL RBCH SCH for purposes other than calibration, if it has sent a RR for DiL RBCH 
SCH before. 



MSC Calibration_Measurement 
















WT_ENV 




WT_RLC 




CC_RLC 




CC_ENV 








RRC_ 


_caiibration_measurer 


nent_re 


q 


















(mac-id, peer-mac-id (broadcast) ) 


RLC_CALiBRATION_iVI EASU F 






d 




DiL RBCH 


iEIVlHNT 






RRC_caiibration_measurement_in 


















(mac-id, peer-mac-id (broadcast)) 













































Figure 13: MSC for RLC_CALIBRATION_MEASUREMENT 

The RLC_CALIBRATION_MEASUREMENT message shall be transmitted using the most robust PHY mode and 
maximum allowed transmit power level in the frequency band of operation. 

The RLC_CALIBRATION_MEASUREMENT message will be received by all other WTs (including the CC), which 
can listen to the sender of this message. Upon reception of this message, each WT (including the CC) shall perform 
physical layer measurement of received signal strength (referred to as RSS2 for Direct Link (TS 101 475 [3])), and shall 
compare it to the previously measured value, if available. In case that the RSS2 value difference exceeds a threshold of 
±6 dB, the corresponding value in the local link quality map shall be updated. This value is reported during the report 
phase as described below. 

6.5.3 Reporting phase 

The reporting phase is started by the calibration-report trigger, broadcast by the CC. The lifetime of the report trigger is 
T_trigger_lifetime, within which a triggered WTl is granted a SCH for DiL RBCH to be sent as report PDU. This PDU 
shall be received by the CC to update the global link quality map. It shall also be received by other WTs to update their 
locally stored (partial) link quality maps, if any. The reporting phase for WTl is completed after the trigger has expired. 
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6.5.3.1 



Calibration-report trigger 



The CC shall trigger the start of the reporting phase by broadcasting the RLC_CALIBRATION_REPORT_TRIGGER 
message using a downlink RBCH SCH (Figure 14). The report trigger shall indicate whether all WTs, or a set of 
selected WTs shall report their calibration measurement results. In case that a set of WTs (up to three) is triggered, the 
corresponding MAC -ID list shall be included in the trigger message. 

MSC Calibration_Report_T rigger 



WT ENV 



WT RLC 



RLC CALIBRATION REPORT TRIGGER 



F!RC_calibration_report_trigger_ind 



( mac-id (broadcast), 

trigger-type, 

mac-ids) 



CC RLC 



CC ENV 



F!RC_calibration_report_trigger_req 



(trigger-type, 
mac-ids) 



(mac-id (broadcast), 

trigger-type, 

mac-ids) 



DL RBCH 



Figure 14: MSC for RLC_CALIBRATION_REPORT_TRIGGER 

The RLC_CALIBRATION_REPROT_TRIGGER message shall be transmitted using the most robust PHY mode. 

After calibration report trigger, the CC shall grant DiL RBCH resources to all, or a set of WTs to transmit calibration 
report PDUs in direct link. Only DiL RBCH SCHs granted within the lifetime of the report trigger of T_trigger_lifetime 
shall be regarded as calibration report PDUs. 

Table 8: RLC-CALIBRATION-REPORT-TRIGGER 



RLC-CALIBRATION-REPORT-TRIGGER -ARG::= SEQUENCE { 



ric-pdu-type RLC-HE-SCH-PDU-TYPE, 
extension-type EXTENSION-TYPE, 
trigger-type TRIGGER-TYPE, 
mac-ids MAC-IDS} 



6.5.3.2 



Calibration report 



Depending on the number of calibration measurements performed, the CC may grant SCHs or LCHs to a triggered WT 
to send its reports. After reception of a (network-wide or selective) calibration-report trigger message from the CC, a 
WT that is granted a SCH or LCH in DiL RBCH as transmitter, shall broadcast a 

RLC_SHORT_CALIBRATION_REPORT or RLC_CALIBRATION_REPORT message during direct link phase 
(Figure 15). It shall set the source MAC -ID of this DiL RBCH to its own MAC -ID. In the case of SCH, 
RLC_SHORT_CALIBRATION_REPORT contains up to two reports. In the case of LCH, 

RLC_CALIBRATION_REPORT may contain up to 22 reports. The field number-of-reports describes the number of 
actual reports contained in the current LCH PDU. 
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A WT, which is granted a DiL RBCH SCH or LCH without having received a report trigger message from the CC 
during the last T_trigger_Hfetime (the report trigger Ufetime) shall not use this DiL RBCH SCH or LCH for calibration 
reporting. It may use this DiL RBCH SCH or LCH for purposes other than calibration, if it has sent a RR for DiL 
RBCH SCH, or LCH, respectively, before. 



MSC Calibration_Report_v1rO 



WT ENV 



WT RLC 



CC RLC 



CC ENV 



alt 



RRC_calibration_report_req 



(mac-id, peer-mac-id (broadcast), 
rep- buff- Stat us, report-list ) 



RLC SHORT CALIBRATION 



({rep-buf-status, 
mac-id-1, rss2-of-wt-1, 
mac-id-2, rss2-of-wt-2}) 



REPORT 



DiL RBCH on SCH 



RLC CALIBRATION REPOR 



DiL RBCH on LCH 



{{rep-buf-status, cal-report-list} ) 



R RC_calibrati on_report_ind 



(mac-id, peer-mac-id (broadcast), 
rep-buff-status, report-list ) 



Figure 15: MSC for RLC_CALIBRATION_REPORT 

The RLC_SHORT_CALIBRATION_REPROT and RLC_CALIBRATION_REPROT messages shall be transmitted 
using the most robust PHY mode, and the maximum allowed transmit power level in the frequency band of operation. 

Table 9: RLC-SHORT-CALIBRATION-REPORT 





RLC-SHORT-CALIBRATION-REPORT-ARG: 


:= SEQUENCE { 


ric-pdu-type 


RLC-HE-SCH-PDU-TYPE, 




extension-type 


EXTENSION-TYPE, 




rep-buf-status 


REP-BUF-STATUS, 




mac-id-1 


MAC-ID, 




rss2-of-wt1 


RSS2-VALUE, 




mac-id-2 


MAC-ID, 




rss2-of-wt2 


RSS2-VALUE} 





Table 10: RLC-CALIBRATION-REPORT 



RLC-CALIBRATION-REPORT-ARG::= SEQUENCE { 



rIc-pdu-type 
extension-type 
rep-buf-status 
cal-report-list 



RLC-HE-LCH-PDU-TYPE, 
EXTENSION-TYPE, 
REP-BUF-STATUS, 
CAL-REPORT-LIST } 
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Each WT shall arrange the measured RSS2 values according to their relative change since the last calibration 
measurement. Those RSS2 values with the highest change shall be reported first. Depending on the granted resources, 
the WT transmits all or part of its reports. In case the WT could not report all RSS2 measurement values that have 
changed by more than ±6 dB, it may indicate in the report PDU by setting the rep-buf-status bit that more resources are 
required. 

From time to time, the CC may want to receive all RSS2 values from a WT. In this case the CC shall grant sufficient 
SCHs or LCHs for DiL RBCH to this WT, so that even those RSS2 values whose changes are below ±6 dB, can be 
included in the calibration report PDU. 

The report list includes the MAC-ID of the measured WT and the corresponding RSS2 value. 

NOTE: The received signal strength of the reports can also be used to check the local topology map. 

6.5.4 Link quality map of tine network 

Once all WTs have reported their measurement results, the CC creates and stores the link quality map of the network, 
which indicates the quality of connectivity between each WT pairs. The link quality map of a network with n associated 
WTs (including the CC), can be represented by a matrix. 

Table 11 : Link quality map of the network 





MAC-ID1 


MAC-ID2 


MAC-IDi 




MAC-IDn 


MAC-ID1 




RSS2 1 ^ 2 


RSS2 1 -^ i 




RSS2 1 -^ n 


MAC-ID2 


RSS2 2 <- 1 




RSS2 2 <- i 




RSS2 2 ^ n 


MAC-IDx 


RSS2 X •e 1 


RSS2 x<-2 






RSS2 X •^ n 


... 












MAC-IDn 


RSS2 n <- 1 


RSS2 n -^ 2 


RSS2 n ^ i 







NOTE 1: RSS2 n <- m represents the DiL received signal strength measured at WT n, when transmitted by WT m. 

A row corresponds to how a given WT receives all other WTs. RSS2 information contained in a row is 
gathered as it is measured by the WT. 

A column corresponds to how a WT is received by all other WTs. RSS2 information contained in a 
column is gathered as it is broadcast to other WTs. 

Each WT stores locally the relevant part of the map, i.e. the corresponding row and column. The CC shall store the 
complete link quality map of the network. The CC may assign a timer to each RSS2 value in the link quality map so as 
to handle partial reporting or some reports received in error. Timers are initialized by the CC when measurements are 
performed. 

The CC may distribute the link quality map of the network to a single or to all WTs in the network. A specific RLC 
PDU is defined for this purpose, called RLC_CALIBRATION_LINKQUALITYMAP. The 
RLC_CALIBRATION_LINKQUALITYMAP may be send upon request of a WT 
(RLC_CALIBRATION_LINKQUALITYMAP_REQUEST) or without an explicit request from a WT. 

NOTE 2: In the latter case the point in time or the period of the link quality map broadcast is out of the scope of the 
present document. 
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Figure 16 gives an overview of the distribution of the link quality map. Without an explicit request from a WT only the 
lower part of the figure is carried out. 



MSC Calibration_LinkQualityMap 



WT ENV 



WT RLC 



CC RLC 



CC ENV 



RRC_calibration_ 
LINKQUALITYMAP_Request_req 



(mac-id, request-type, mac-id) 



RRC_calibration_ 
LINKQUALITYMAP_Request_cnf 



( mac-id(broadcast), 

map-ext-ind, 

complete- report- list) 



DiLRBCH 



RLC_CALIBRATION_ 
LINKQUALITYMAP REQUEST 



(request-type, mac-id) 



RLC_CALIBRATION_ 

LINKQUALITYMAP_ 

REQUEST ACK 



( map-ext-ind, 

complete- report-list) 



RRC_calibration_ 
LINKQUALITYMAP_Request_ind ^ 

(mac-id, request-type, mac-id) 

RRC_calibration_ 
LINKQUALITYMAP_Request_rsp 

( mac-id(broadcast), 
map-ext-ind, 
complete- report-list) 



Figure 16: MSC for RLC_CALIBRATION_LINKQUALITYMAP_REQUEST and 
RLC_CALIBRATION_LINKQUALITYMAP 

The RLC_CALIBRATION_LINKQUALITYMAP_REQUEST and RLC_CALlBRATION_LINKQUALITYMAP 
messages shall be transmitted using the most robust PHY mode. 

Table 12: RLC-CALIBRATION-LINKQUALITYMAP-REQUEST 



RLC-CALIBRATION-LINKQUALITYMAP-REQUEST-ARG::= SEQUENCE { 



ric-pdu-type RLC-HE-SCH-PDU-TYPE, 

extension-type EXTENSION-TYPE, 

mac-id MAC-ID, 

request-type REQUEST-TYPE } 



Table 13: RLC-CALIBRATION-LINKQUALITYMAP 



RLC-CALIBRATION-LINKQUALITYMAP-ARG: 


:= SEQUENCE { 


rIc-pdu-type RLC-HE-LCH-PDU-TYPE, 




extension-type EXTENSION-TYPE, 




map-ext-ind MAP-EXT-IND, 




complete-report-list COMPLETE-REPORT-LIST } 





Within the RLC_CAL1BRAT10N_L1NKQUAL1TYMAP_REQUEST a parameter called request-type indicates 
whether the whole map is requested or only a partial map. A partial map corresponds to a column in Table 1 1, which 
includes the RSS2 values with which all other WTs have received the RLC_CALlBRATION_MEASUREMENT PDU 
from the WT with mac-id. 
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To unify complete and partial quality map encoding, the link quality map shall be encoded by columns. This means that 
each (partial) report consists of the MAC-ID of the WT that has sent RLC_CALIBRATION_MEASUREMENT, and N 
times the MAC -ID, RSS2 value and the age of the measurement for each of the N receiving WTs. A complete report list 
is composed of several partial reports (for all sending WTs). An age of measurement field has been included to indicate 
when the RSS2 value has been updated for each of the receiving WTs. The field map-ext-ind (map-end, map-continue) 
indicates whether more RLC_CALIBRATION_LINKQUALITYMAP PDUs will follow, and can be used in the case 
that the link quality map cannot be transmitted in a single LCH PDU. 

The encoding of RLC_CALIBRATION_LINKQUALITYMAP is the same for partial and complete link quality maps, 
but partial RLC_CALIBRATION_LINKQUALITYMAP shall be transmitted on DL DCCH to the sender-WT of the 
report whereas complete RLC_CALIBRATION_LINKQUALITYMAP shall be broadcast on DL RBCH. 

6.6 DLC User Connection Control 
6.6.1 Fixed Slot Allocation for DM (OCC/OWT) 

Fixed Slot Allocation is a mode of capacity allocation negotiated during DUC setup. With FS A a fixed amount of LCHs 
at a fixed position in the MAC Frame is allocated. This allocation is valid until a DUC modify or DUC release 
procedure is used. No RR or RG shall be used for the LCHs of DUCs in FSA mode. 

If Fixed Slot Allocation is supported, it shall be performed as described below. 















MAC Frame 


FSA 




MAC Frame 


FSA 





Figure 17: Example for a fixed slot allocation 

Figure 17 shows an example for a Fixed Slot allocation in the middle of the MAC Frame. The position in the MAC 
Frame is fixed and cannot be changed with normal RGs. To change the position, the number of LCHs, or the PHY 
mode of an FSA, a DUC modify shall be performed. 

A typical usage of FSA would be in combination with unacknowledged (error) mode and with FEC. Nevertheless the 
use of any other combination of error control is possible. In case the acknowledged or ARQ mode is used, a WT shall 
decode the FCCH to look for SCH RGs. These SCHs may be used for ARQ discard and acknowledge messages. In 
unacknowledged mode a WT may not decode the FCCH, because no need for SCHs exists. 

The FSA specific information in the set-up, release or modify messages is contained in an fsa-descr field inside the 
duc-direction-descr (see TS 101 761-2 [2]). A proposed FSA parameter setting (by a WT) is called FSA Resource 
Request (FSA-RR). The definite FSA parameter setting (by the CC) is called FSA Resource Grant (FSA-RG). The 
setting of the parameters in the fsa-descr in case of an FSA-RR and an FSA-RG is treated in clause 7.6.1. 

Depending on the RLC procedure FSA-RR and FSA-RG are contained in the following messages: 

• In the WT initiated Unicast FSA DUC Setup the sender includes the FSA-RR in the RLC_DM_SETUP message 
that is sent to the CC. The FSA-RG is sent back to the initiating WT (sender) within the RLC_DM_CONNECT 
message. The receiver is informed about the FSA-RG in the RLC_DM_SETUP message sent to him by the CC. 

• In the CC initiated Unicast FSA DUC Setup no FSA-RR is necessary. The FSA-RG is sent to the respective WT 
in the RLC_DM_SETUP PDU, generated by the CC at the beginning of the procedure. 

• In the WT initiated Multicast FSA DUC Setup the sender includes the FSA-RR in the RLC_DM_MC_SETUP 
message that is sent to the CC. The FSA-RG is sent back to the initiating WT (sender) within the 
RLC_DM_MC_CONNECT message. Every receiver is informed about the FSA-RG in its respective 
RLC_DM_MC_SETUP message sent to him by the CC. 

• In the CC initiated Multicast FSA DUC Setup no FSA-RR is necessary. The FSA-RG is sent to every WT in the 
Multicast group by the RLC_DM_MC_SETUP PDU, generated by the CC at the beginning of the procedure. 

• In the WT initiated DM-MODIFY procedure (Unicast or Multicast) the new FSA-RR is included by the 
initiating WT in the RLC_DM_MODIFY_REQ PDU. The new FSA-RG is sent by the CC to every receiver in a 
RLC DM MODIFY PDU. 
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• In the CC initiated DM-MODIFY procedure (Unicast or Multicast) no FSA-RR is necessary. The new FSA-RG 
is sent to the sender as well as every receiver in the RLC_DM_MODIFY_REQ PDU. 

Note, that depending on who has initiated the DUC Setup, the RLC_DM_SETUP message either contains the FSA-RR 
or the FSA-RG. Regarding the starting MAC frame that is signalled to the sender and all receivers within the FSA-RG 
some timing constraints have to be considered, what is dealt with in clause 6.6.1.2. 

If Fixed Slot Allocation has been accepted for a DUC, CC and WT perform the following operations in addition. 

6.6.1.1 CC operation 

The CC operation is the following: 

• The CC shall not schedule LCHs (using RGs in the FCCH), or RCHs (in the BCCH) for the part of the MAC 
frame where Fixed Slot Allocation is used. SCHs shall only be scheduled when acknowledged mode (ARQ) is 
used. 

• No RGs shall be generated for an FSA connection in unacknowledged mode. For an FSA connection in 
acknowledged mode, SCH RGs shall be generated for WT discards and acknowledgements. 

• The CC may change the Fixed Slot Allocation by using the DUC_MODIFY or DUC_RELEASE procedure. 

6.6.1.2 WT operation 

The WT operation is the following: 

• After DUC setup the transmitting WT shall start transmission in the specified start-mac-frame. 

• After DUC setup the receiving WT shall start receiving in the specified start-mac-frame. 

• No RR shall be generated for an FSA connection in unacknowledged mode. In acknowledged mode only RRs 
for SCHs may be generated (in case the number of SCHs granted by the CC are not sufficient for ARQ 
operation). 

• In order to change the PHY Mode (link adaptation) the WT shall use the DUC_MODIFY procedure. 

6.6.1.3 Timing of FSA 

The beginning and modification of FSA is valid from a signalled MAC Frame on. The value start-mac-frame in the 
FSA-RG gives the exact MAC frame to start FSA. start-mac-frame is the absolute MAC Frame number as determined 
by the MAC frame counter in the BCCH. To overcome the 4 bit limitation of the MAC Frame Counter parameter in 
BCCH, Start MAC frame is furthermore offset by a repetition-counter parameter, which gives the number the 
frame-count value repeats in BCCH after the reception of the FSA-RG (1 repetition corresponds to 16 MAC frames). 
The reference for the offset is the MAC frame the FSA-RG is received by the respective WT. That means that the RLC 
instance shall know in which MAC frame it received the FSA-RG in order to determine the right MAC frame to start 
FSA. start-mac -frame of every receiver as well as start-mac-frame of the sender shall always be set such that it is 
guaranteed that the time until the receiver starts reception of FSA is shorter or equal to the time until the sender starts 
sending with FSA. As an example this implies that the start-mac-frame values of every receiver are shorter than the 
start-mac -frame value of the sender, if all FSA DUC descriptors are transmitted in the same frame. The sender shall 
never start sending data before the starting MAC frame of FSA, but may start in a later frame than its start-mac-frame. 
It is therefore not necessary (but still possible) that the CC reserves capacity for the sender in a frame before the starting 
MAC frame of FSA. The CC shall reserve the negotiated capacity for FSA at the latest from the starting MAC frame 
on. 

start-mac -frame is 16 bits long. Its 4 MSB are used to encode the MAC Frame Counter value c?i\\ed frame-count, and 
its 12 LSB are used to encode the repetition-counter value. Either coding is binary. With this length of the 
start-mac -frame parameter the maximum time between the FSA-RG and the start of the FSA is 131 s. 

EXAMPLE: start-mac-frame = 00000000000 1 00 1 

The MAC frame to start with FSA is the second time (because of offset = 000000000001) the 
MAC Frame Counter in the BCCH shows the value 0010 after the reception of the FSA-RG. 
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Each WT supporting FSA shall be able to start FSA two MAC frames after the MAC frame the FSA-RG is received. 
For example, if FSA-RG is received in MAC frame #2, the WT shall be able to start FSA in any DiL position of MAC 
frame #4. The CC shall set the Start MAC Frame value such that it is possible to complete the DUC setup/modify 
procedure before the Start MAC Frame is reached with a high probability. 



MSC Direct_Link_Multicast_Setup_ 



1(1) 



WT_AS SOC IAIED_WrrH_C c 



MdticastGroupJoin 




Senderinitiated 



^ 



DiiECt_Lmk_Multicas t_ 
_Set up_S ende r_i lit iate d 



peer_mac_id i s t he 
mutlticast macjd 

souice-mac-id is the mac-id 
of the multicast sentfer 



The CC setup connections K 
withall tCTninalsthat have 
joined the group 



n is the number of 
joined multicast 
receivers 



loop <l,n> Direct_Link_Milticast_ 
_Setup_CC_initiated 



DiiECt_Link_Multicas t_ 
_Connect_com fiction 



MULTICAST_CONNECriON_ESTABUSHED 



Figure 18: Overview of DiL multicast setup 
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6.6.2 Multicast in DiL pinase 
6.6.2.1 General 

The Direct Link can also be used for multicast connections. DiL multicast without QoS negotiation is already supported 
by documents TS 101 761-1 [1], TS 101 761-2 [2]. 

If Direct Link Multicast is supported, it shall be performed as described below. 

A multicast connection is identified by three numbers: 

• Destination MAC_ID, numbers from 224 to 254 shall be used; 

• Source MAC_ID, mac_id of the WT that is the sender of this group; 

• DLCCJD = 63 shall be used. 

As is shown in Figure 18, the first action for a WT is to join the muticast group by using the RLC_GROUP_JOIN 
message. Then the CC replies with a dynamically selected multicast MAC ID within the range {224, 254}. This MAC 
ID, in conjunction with DLCC ID = 63, will be used as a unique identifier for the multicast group. 

A multicast group that does not require QoS parameter negotiation shall start multicast immediately without performing 
the DiL multicast setup procedure specified in the following clauses. In this case, each WT of a multicast group can 
become the sender of this multicast group at any time. It just needs to send out a RR for DiL UMCH, in which it sets the 
destination MAC ID to the assigned multicast MAC ID, the source MAC ID to its own MAC ID, and DLCC ID to 63. 

Before a WTl can become a sender of a multicast group which requires QoS parameter negotiation, it shall first run a 
sender-initiated DM_Multicast_Setup procedure with the CC. Before the DM_Multicast_Setup procedure is 
successfully completed, the WTl shall not begin to transmit data. After the multicast setup initiation by WTl, the CC 
shall forward the multicast setup request message to each multicast receiver WTx that has joined the multicast group. 

The CC can also initiate a DM_Multicast_Setup even if it is not the sender, in that case it has also to send a multicast 
setup request to the sender WTl. Then, the CC shall perform a multicast setup forwarding procedure for each receiver 
WTx of the multicast group. The setup request to the sender WTl and the setup forwarding to each receiver WTx uses a 
common procedure, which is the same as the setup forwarding procedure used in the sender-initiated case. 

In both sender-initiated and CC-initiated cases, the CC shall send a RLC_DM_MC_CONNECT_COMPLETE message 
to the sender WTl after it has forwarded all setup request messages to all other WTs of the group. The 
RLC_DM_MC_CONNECT_COMPLETE message shall be sent only when at least min-req-receivers receivers have 
positively acknowledged the multicast setup request, min-required-receivers is a parameter in the 
RLC_DM_MC_SETUP message, which will be set by the initiating WT, or the CC. 

Another parameter set by the initiating WT is the max_setup_time. This parameter is coded exponentially: 

T _ dm _ setup _wt = 4™^"--*'' "P- "'"^ [MacFrames] 

After transmitting the first RLC_DM_MC_SETUP message to a receiver WTx, the CC starts the timer T_dm_setup_wt. 
If more than or equal to min_required_receivers WTs have completed the setup procedure until the timer 
T_dm_setup_wt expires, the multicast connection is established. That confirmation is given by the CC to the sender 
WTl by sending it a RLC_DM_MC_CONNECT_COMPLETE message. Then, the sender WTl is allowed to send data 
in the specified multicast DUC. 

If a terminal responds to the CC after the connection setup has finished it is allowed to receive the multicast DUC, 
although the earlier data might be lost for this WT. If a terminal joins the group after the setup procedure is completed, 
it shall wait until the CC informs it of the ongoing multicast connection. The CC shall inform later joining WTx of the 
connection parameters by performing the setup forwarding procedure for the joining receiver WTx. 

The parameters of an established multicast connection can be modified by a DM_Multicast_Modify procedure. The 
DM_Multicast_Release procedure is used to release an established multicast connection. 

If DiL Multicast is supported, the DiL multicast setup is mandatory for multicast groups which make use of Fixed 
Capacity Assignment specified in TS 101 761-1 [1] or Fixed Slot Allocation as specified in clause 6.6.1 of the present 
document. 
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Referring to the following MSCs the CC can act as the multicast sender WTl, or as one of the multicast receivers WTx. 
In this case all multicast related RLC messages between this WTl and the CC, or between this multicast receiver WTx 
and the CC, shall be exchanged internally in the CC device. 

All multicast setup, modify and release procedures specified in the following shall use unicast DL DCCH and UL 
DCCH for message exchange between the CC and multicast sender WTl, and between the CC and a particular 
multicast receiver WTx, respectively. As defined for CM, the MAC ID of the uplink and downlink unicast DCCH shall 
be always set to the MAC ID of the WT, which sends or receives this DL or UL DCCH. 



6.6.2.2 



DiL MULTICAST SETUP, WT-initiated (OCC/OWT) 



If DiL Multicast is supported and a WTl of a DiL multicast group wants to become a sender of this multicast group, it 
shall initiate this procedure if the connection requires QoS parameter negotiation. The CC and WTl may negotiate e.g. 
FSA or FCA parameters. Referring to the following MSC (Figure 19), the source MAC ID is the MAC ID of WTl. This 
MAC ID is needed for the CC to identify the sender WTl. 

For exchanging the link parameters the initiating WTl transmits a RLC_DM_MC_SETUP message to the CC. The CC 
shall respond by sending the RLC_DM_MC_CONNECT message, which is acknowledged by the initiating WTl. In 
this message the CC can modify the QoS parameters proposed by the initiating WTl. 

The direction parameter of the multicast due-descriptor shall be set to simplex-forward for the multicast sender WTl, 
and set to simplex-backward for all multicast receivers WTx. 



MSCE)irect_Link_Multicast_Setup_Sender_initiated 



(X.RLC 



DUC_dm_mc_setup_req 



RLC_DM_MC_SETUP 



( {DUC-DM-MC-SETUP-ARP) 
T_dm_mc_setup_wt 



( {peer_niac_id, 
source_mac_id, 
cljd, 

duc_ext_ind, 
inin_req_receivers, 
cl_conn_attr_length, 
duc_descr_list, 
cl_comn»n_attr) ) 



DUC_dm_mc_setup_ind 
( (DUC-DM-MC-SETUP-ARP) 

DUC_dm_mc_connect_req 



RLC_DM_MC_CONNECT 



DUC_dm_mc_connect_ind 



[DUC-DM-MC-CONNECT-ARG) ) 
DUC_dm_iiic_connect_rsp 



( {peer_inac_id, 
source_mac_id, 
clJd, 
cl_conn_attr_length, 

duc_descr_list} ) 



(DUC-DM-MC-CONNECT-ARG) ) 



T_dm_mc_connect_cc 



{DUC-DM-MC-CONNECT-ACK-Aat;) 



, RLC DM MC_CONNECr_ACK 



( {peer_nmc_id, 
source_inac_id, 
clJd, 

cl_conn_attr_length, 
dlcc_descr_list} ) 



DUC_dm_mc_connect_cnf 



( (DUC-DM-MC-C0NNECr-ACK-A8G 



Figure 19: MSC Direct_Link_Multicast_Setup_WT_CC 
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Table 14: RLC-DM-MC-SETUP 



RLC-DM-MC-SETUP-ARG::= SEQUENCE { 


ric-pdu-type 


RLC-HE-LCH-PDU-TYPE, 


extension-type 


EXTENSION-TYPE 


peer-mac-id 


MAC-ID, 


source-mac-id 


MAC-ID, 


cl-id 


CL-ID, 


duc-ext-ind 


BOOLEAN, 


min-req-receivers 


INTEGER(0..255), 


cl-conn-attr-length 


INTEGER(0..31), 


duc-descr-list DUC-DESCR-LIST, 


cl-common-attr 


CL-COMMON-ATTR } 



The parameter source-mac-id is used to identify the sender WTl in the case of a sender-initiated connection setup. In 
the case of a CC-initiated connection setup this parameter is used to inform a WTl that it is to become the sender. 

Table 15: RLC-DM-MC-CONNECT 





RLC-DM-MC-CONNECT-ARG: 


:= SEQUENCE { 


rIc-pdu-type 


RLC-HE-LCH-PDU-TYPE, 




extension-type 


EXTENSION-TYPE 




peer-mac-id 


MAC-ID, 




source-mac-id 


MAC-ID, 




cl-id 


CL-ID, 




cl-conn-attr-length 


INTEGER(0..31), 




duc-descr-list 


DUC-DESCR-LIST} 





Table 16: RLC-DM-MC-CONNECT-ACK 





RLC-DM-MC-CONNECT-ACK-ARG: 


:= SEQUENCE { 


rIc-pdu-type 


RLC-HE-LCH-PDU-TYPE, 




extension-type 


EXTENSION-TYPE 




peer-mac-id 


MAC-ID, 




source-mac-id 


MAC-ID, 




cl-id 


CL-ID, 




cl-conn-attr-length 


INTEGER(0..31), 




dicc-descr-list 


DUC-DESCR-LIST} 
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The s ender-ini tiated setup procedure in 

MSCE>irect_Link_Miilticast_Setup_Sender_initiated 



DUC_dm_nic_setup_req 



RLC_DM_MC_SETUP 



( (DUC-DM-MC-SETUP-ARfl) 

T_dm_mc_setup_wt 



( {peer_mac_id, 
source_mac_id, 
cljd, 

duc_ext_ind, 
min_req_receivers, 
cl_comi_attr_length, 
duc_descr_list, 
cl_common_attr) ) 



( {DUC-DM-MC-SETUP-AR$}} 



DUC_dm_mc_connect_req 



RLC_DM_MC_CONNECT 



DUC dm mc connect ind 



[DUC-DM-MC-CONNECr-ARG} 
DUC_dm__mc_connect_rsp 



( {peer_mac_id, 
source_mac_id, 

clJd, 
cl_conn_attr_length, 

duc_descr_list} ) 



{DUC-DM-MC-CONNECr-ACK-ARCr}_ 



, RLC_DM_MC_CONNECr_ACK 



( {peer_mac_id, 
source_niac_id, 
clJd, 

cl_conn_attr_length, 
dlcc_descr_list) ) 



DUC_dm_mc_setup_ind 



{DUC-DM-MC-CONNECr-ARG} ) 



T_dm_mc_connect_cc 



DUC_dm_mc_connect_cnf 



( {DUC-DM-MC-CONNECr-ACK-AIiG 



Figure 19 shall be followed by a setup forwarding procedure for each multicast receiver, as is shown in Figure 20. The 
CC forwards the RLC_DM_MC_SETUP message to each multicast receiver WTx. The peer MAC ID in the setup 
procedure's messages shall be set to the MAC ID of the multicast group, and source MAC ID set to the MAC ID of 
WTl. 
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MSCDirect_linlc_Multicast_Setup_CC_imtiated 



WT includes all multicast receivers WTx and it may 

include the multicast sender WTl if the connection is sender initiated 



^ 



CC_ENV 



{DUQDM- 



DUC_dm_mc_setup_ind 



IDUC-DM-C-SETUP-ARG) ) 



DUC_dm_mc_connect_req 



( IDUC-DM-MC-CONECT-AR^) 

X 

T dm mc connect wt 



E >UC_dm_mc_connect_cnf 



MC-CONNECT-ACK-ARG) ) 



RLC_DM_MC_SETUP 



( {peer_mac_id, 
source_mac_id, 
cljd, 
duc_ext_ind, 
min_req_receivers, 
cl_conn_attr_length, 
duc_descr_Ust, 
cl_common_attr} ) 



^7(DLP-DM-MC-SETUP-ARG) ) 
T_dm_mc_setup_cc 



RLC DM MC CONNECT 



( {peer_mac_id, 
source_mac-id, 
clJd, 

cl_conn_attr_length, 
duc_descr_list } ) 



RLC_DM_MC_CONNECr_ACK 



( {peer_mac_id, 
source_mac_id, 
clJd, 
cl_conn_attr_length, 

dlcc_descr_list} ) 



DUC_dm_mc_setup_req 



DUC_dm_mc_connect_ind 



( (DUC-DM-MC-CONNECr-AR55) 
DUC_dm_mc_connect_rsp 



{DUQDM-MC-CONNEC -ACK-ARG) ) 



DUC_estabUshed 



Figure 20: MSC Direct_Link_Multicast_Setup_forwarding 

The CC then waits for the muhicast receivers to respond. If one or more multicast receivers do not respond within 
max_setup_time, the CC may retransmit the RLC_DM_MC_SETUP message to each of those muhicast receivers. 
Further repetitions are also possible. 

After min-req-receivers receivers have accepted the multicast setup within max-setup-time, the CC shall respond to 
WTx by sending RLC_DM_MC_CONNECT_ACK messages. Otherwise, it shall abort the multicast connection setup 
by performing a CC-initiated multicast release for each receiver WTx that is already involved in the setup procedure, 
and the sender WTl. 

If at least min_required_receivers WTx respond positively within max-setup-time, which has been exchanged between 
initiating WTl and CC, the multicast connection is accepted by the CC. The CC transmits a 

RLC_DM_MC_CONNECT_COMPLETE message to the initiating WTl. The initiating WTl shall respond with a 
RLC_DM_MC_CONNECT_COMPLETE_ACK message (Figure 21). 
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MSC Direct_Link_Multicast_Connect_completion 
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Figure 21 : MSC Direct_Link_Multicast_Setup_Completion 



Table 17: RLC-DM-MC-CONNECT-COMPLETE 



RLC-DM-MC-CONNECT-COMPLETE-ARG::= SEQUENCE { 



ric-pdu-type RLC-HE-LCH-PDU-TYPE, 

extension-type EXTENSION-TYPE 

peer-mac-id IVIAC-ID, 

source-mac-id IVIAC-ID, 

dicc-id-list DLCC-ID-LIST} 



Table 18: RLC-DM-MC-CONNECT-COMPLETE-ACK 



RLC-DM-MC-CONNECT-COMPLETE-ACK-ARG::= SEQUENCE { 



ric-pdu-type RLC-HE-LCH-PDU-TYPE, 

extension-type EXTENSION-TYPE 

peer-mac-id iVIAC-ID, 

source-mac-id iVIAC-ID} 



Fixed Slot Allocation 

The FSA-RR is sent in the RLC_DM_MC_SETUP message from the initiating WTl to the CC. 

The FSA-RG is transmitted from the CC to each receiver WTx in the RLC_DM_MC_SETUP message. 

The FSA-RG to the initiating WTl is sent within the RLC_DM_MC_CONNECT message. 
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6.6.2.3 DiL multicast setup for a new joining WT (OCC/OWT) 

This clause describes the cases that a new WT, that supports DiL Multicast, has joined the group and is informed by the 
CC of the multicast connection parameters. 

The CC shall re-use the setup forwarding procedure depicted in Figure 20 after a new WT has joined the multicast 
group using the JOIN procedure to let the new WT know the MAC ID of the multicast sender and other connection 
parameters. After this multicast setup procedure is completed, this new WT might not be able to receive the multicast 
data. In this case, it may perform the DiL Power Control procedure for multicast/broadcast to request the multicast 
sender to increase the transmit power. No further action is specified, if the new WT still cannot decode the multicast 
data correctly. 

The multicast setup forwarding procedure for a new joining multicast receiver is transparent to the multicast sender. 

6.6.2.4 DiL multicast setup, CC initiated (OCC/OWT) 

This clause describes the case that a new multicast connection from a sender WTl (also the CC may be the sender), that 
supports DiL multicast, to the multicast group (also the CC may be member of this group) is to be established by the 
CC. 

The CC-initiated multicast uses the procedure in Figure 20 for the multicast sender and all receivers. The CC shall first 
transmit a RLC_DM_MC_SETUP to the sender WTl, at this stage the sender can negotiate parameters of the 
connection with the CC. The peer_MAC_ID parameter in the RLC_DM_MC_SETUP message shall be set to the 
MAC-ID of the multicast group. The sender WTl is informed that it is to become the sender by looking at the 
source_mac_id field in the RLC_DM_MC_SETUP message, which is set to the MAC ID of WTl. 

The sender WTl shall respond with a RLC_DM_MC_CONNECT and the CC shall send the acknowledgement to 
confirm parameters. Then the CC shall repeat the setup forwarding procedure in Figure 20 for each joined multicast 
receiver WTx. 

The CC then waits for WTs to respond. If one or more multicast receiver WTs does not respond within 
max_setup_time, the CC may retransmit the RLC_DM_MC_SETUP message using a downlink unicast DCCH. Further 
repetitions are also possible. The multicast sender WTl shall respond positively within max_setup_time. Otherwise, the 
CC-initiated DiL_Multicast_Setup procedure fails. 

If at least min_required_receivers WTs (the sender excluded) of the multicast group respond within max_setup_time to 
the RLC_DM_MC_SETUP message, the multicast connection is accepted by the CC. A negotiation of max_setup_time 
is not needed, if the CC is the sender of the multicast connection. If for any reason the multicast setup fails, the CC shall 
abort the multicast setup procedure by performing a CC-initiated multicast release for the multicast sender and each 
multicast receiver already involved in the setup procedure. 

If the sender and min_req_receivers receivers have accepted the multicast setup, the multicast setup completion 
procedure in Figure 21 shall be finally performed. The CC shall transmit a RLC_DM_MC_CONNECT_COMPLETE 
message to the sender WTl or to itself (if CC is sender), which shall be responded by a 
RLC_DM_MC_CONNECT_COMPLETE_ACK message. 

Fixed Slot Allocation 

No FSA-RR is needed because a recommendation to the CC itself does not make sense. 

The FSA-RG is sent in the RLC_DM_MC_SETUP message from the CC to the initiating WT and the receiving WTs. 
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6.6.2.5 Modify multicast (OCC/OWT) 



The modification of the muhicast connection characteristics can be sender-initiated or CC-initiated. If it is 
sender-initiated, the muhicast sender WTl shall send a RLC_DM_MC_MODIFY_REQ to the CC. This triggers the CC 
to perform multicast modify by sending RLC_DM_MC_MODIFY to the multicast sender WTl (Figure 22) and to each 
of the multicast receivers WTx (Figure 23). The RLC_DM_MC_MODIFY contains a parameter field start-mac-frame, 
which tells all WTs when the modified multicast shall start. If it is CC-initiated, the CC shall perform the multicast 
modify procedure without the request from the multicast sender. In this case, the procedure in Figure 23 shall also 
perform for the multicast sender. 

A timer T_rsp is set similar to the multicast setup procedure. If not all WTs have responded by sending a 
RLC_DM_MC_MODIFY_ACK until the timer expires the CC shall retransmit the RLC_DM_MC_MODIFY message 
on DL DCCH to each of the concerned WTs. 

The multicast setup completion procedure shall not be used in case of modifying a multicast DUC. 

The connection parameters are changed after all WTs of the multicast group have responded or all repetitions to the not 
responding WTs have finished. 

If the sender does not accept the RLC_DM_MC_MODIFY message from the CC, the CC shall release the multicast 
connection for all involved WTs. If one or more multicast receiver does not accept the RLC_DM_MC_MODIFY 
message from the CC, the CC shall release the connection for these receivers. In the latter case it shall only release the 
multicast connection for all other WTs (including the sender), if the number of the remaining receivers is less than 
min_required_receivers. 

The exact start point to change the multicast connection is given by the start-mac-frame parameter, which is sent from 
the CC to all multicast WTs. start-mac-frame is the absolute MAC frame number as determined by the MAC frame 
Counter in the BCCH. To overcome the 4 bit limitation of the MAC frame counter parameter in BCCH, 
start-mac-frame is furthermore offset by a MAC frame cycle parameter, which gives the number, the MAC frame 
Counter value repeats in BCCH after the reception of the RLC_DM_MC_MODIFY message (1 repetition corresponds 
to 16 MAC frames). The reference for the offset is the MAC frame the RLC_DM_MC_MODIFY PDU is received. 
That means that the RLC instance shall know in which MAC frame it received the RLC_DM_MC_MODIFY message 
in order to determine the right MAC frame to change the multicast connection. The CC should set start_mac_frame 
sufficiently late to allow all WTs to be prepared for this change. 

start_mac_frame is 16 bits long. Its 4 MSB are used to encode the MAC Frame Counter value, and its 12 LSB are used 
to encode the MAC Frame Cycle value. Either coding is in binary. With this length of the start_mac_frame parameter 
the maximum time between the RLC_DM_MC_MODIFY PDU and the multicast connection change is 131 s. 

EXAMPLE: start_mac_frame = 0010 000000000001 

The MAC frame to change the multicast connection is the second time (because of 

offset = 000000000001) the MAC Frame Counter in the BCCH shows the value 0010 after the 

reception of the RLC_DM_MC_MODIFY PDU. 

If a multicast connection is used for FSA, the start_mac_frame value in the RLC_DM_MC_MODIFY message shall be 
equal to the start-mac-frame value in the FSA-RG parameter, which is also included in RLC_DM_MC_MODIFY. 



£75/ 



54 



ETSI TS 101 761-4 VI .3.2 (2002-01) 



MSC Direct_Link_Multicast_Modify_Sender_initiatecl 
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Figure 22: MSC Direct_Link_Multicast_Modify_WT_CC 
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Figure 23: lUISC Direct_Linl<_IU!ulticast_IUIodify_CC_WT 
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Table 19: RLC-DM-MC-MODIFY-REQ 





RLC-DM-MC-MODIFY-REQ-ARG: 


:= SEQUENCE { 


ric-pdu-type 


RLC-HE-LCH-PDU-TYPE, 




extension-type 


EXTENSION-TYPE, 




peer-mac-id 


MAC-ID, 




source-mac-id 


MAC-ID, 




cl-conn-attr-length 


INTEGER(0..31), 




duc-descr-list 


DUC-DESCR-LIST} 





Table 20: RLC-DM-MC-MODIFY 





RLC-DM-MC-MODIFY-ARG: 


:= SEQUENCE { 


rIc-pdu-type 


RLC-HE-LCH-PDU-TYPE, 




extension-type 


EXTENSION-TYPE, 




peer-mac-id 


MAC-ID, 




source-mac-id 


MAC-ID, 




start-mac-frame 


START-MAC-FRAME, 




cl-conn-attr-length 


INTEGER(0..31), 




duc-descr-list 


DUC-DESCR-LIST} 





Table 21 : RLC-DM-MODIFY-ACK 





RLC-DM-MC MODIFY-ACK-ARG: 


:= SEQUENCE { 


rIc-pdu-type 


RLC-HE-LCH-PDU-TYPE, 




extension-type 


EXTENSION-TYPE, 




peer-mac-id 


MAC-ID, 




source-mac-id 


MAC-ID, 




start-mac-frame 


START-MAC-FRAME, 




cl-conn-attr-length 


INTEGER(0..31), 




dicc-descr-list 


DUC-DESCR-LIST} 





6.6.2.6 



Release multicast (OCC/OWT) 



The release can be CC-initiated or WT-initiated, where WT can be the multicast sender or one of the receivers. In case 
of a CC-initiated release the CC shall transmit a RLC_DM_MC_RELEASE to the WT, which it wants to disconnect 
from the multicast. The WT shall reply with RLC_DM_MC_RELEASE_ACK. If the sender has been released, the 
CC-initiated multicast release as shown in Figure 24 shall be repeated for each multicast receiver to stop its receive 
operation. 

In case of a sender-initiated release, the sender of the multicast group shall send a RLC_DM_MC_RELEASE to the 
CC. The CC shall send back a RLC_DM_MC_RELEASE_ACK message to the sender (Figure 25). The CC shall then 
start the CC-initiated multicast release in Figure 24 for each multicast receiver to stop its receive operation. If a 
multicast receiver initiates the WT-initiated release in Figure 25, the CC shall acknowledge by replying with 
RLC_DM_MC_RELEASE_ACK. In this case, the CC shall only release the multicast connection for all other WTs 
(including the sender), if the number of the remaining receivers is less than min_required_receivers. 
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MSC Direct_Link_Multicast_Release_CC_initiate d 
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Figure 24: MSC Direct_Link_Multicast_Release_CC_WT 
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Figure 25: IWSC Direct_Link_l\/lulticast_Release_WT_CC 



Table 22: RLC-DI\/I-I\/IC-RELEASE 





RLC-DM-MC-RELEASE-ARG: 


:= SEQUENCE { 


ric-pdu-type 


RLC-HE-LCH-PDU-TYPE, 




extension-type 


EXTENSION-TYPE, 




peer-mac-id 


MAC-ID, 




source-mac-id 


MAC-ID, 




dicc-id-list 


DLCC-ID-LIST, 




release-causeRELEASE-CAUSE} 
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Table 23: RLC- DM-MC- RELEASE-ACK 



RLC-DM-MC-RELEASE-ACK-ARG::= SEQUENCE { 



ric-pdu-type RLC-HE-LCH-PDU-TYPE, 

extension-type EXTENSION-TYPE, 

peer-mac-id IVIAC-ID, 

source-mac-id IVIAC-ID, 

dicc-id-list DLCC-ID-LIST} 



6.7 Dynamic CC selection (IVICC) 



If dynamic CC selection is supported, it shall be performed as described below. Devices supporting the CC selection are 
called CC-capable devices. All CC-capable H/2-HDs shall support dynamic CC selection. For basic WTs the dynamic 
CC selection is not applicable. 

The dynamic CC Selection ensures that within one radio cell or subnet only one CC is established. It is performed in a 
decentralized and autonomous way by each CC-capable device. The selection does not take into account the best 
position or the best capabilities of a CC-capable device because the necessary measurements are not available at this 
stage. The CC is selected at random based on a contention process. However, the user can prevent an unfavourably 
located CC-capable device from being the CC by disabling this CC-capable device to participate in the CC selection 
process. 

6.7.1 Principle 

Each CC-capable device first tries to become a WT. The first step is to scan all available frequencies for already 
running CCs (initial scanning process, see clause 6.7.2). If no CC has been found or association to the CCs is not 
possible (e.g. it is the CC of the neighbour or a CC/AP without HE capability) each CC-capable device shall try to 
become a CC by performing the CC Selection protocol. Each CC-capable shall also have a user interface, which enables 
the user to disable the CC Selection function, if the corresponding CC-capable device is to be excluded from the CC 
selection process. A CC-capable device with disabled CC Selection function shall only be able to act as a basic WT. 

In order to prevent multiple CC-capable devices from becoming CC, a CC collision resolution, i.e. the CC Selection 
protocol, is performed. The basic idea is that each CC-capable device transmits a "Probing Beacon" from time to time 
and senses the channel in between. The Probing Process, i.e. transmitting of Probing Beacons and sensing the Probing 
Channel to detect beacons from other devices, is interrupted for frequency scanning phases in which all other available 
frequencies are scanned for another CC-capable device. Each CC-capable device which senses a "Probing Beacon" 
withdraws from the CC Selection, performs a back-off and starts with the initial scanning process again. This may result 
in a new CC Selection process. 

After a predefined time the CC-capable device which has not sensed anything survives and becomes CC. Of course it is 
not possible to resolve all collisions with this protocol. There is still a residual collision probability. 

6.7.2 Initial scanning process 

The scanning of frequency channels is not defined in the present document. For detection and selection of a CC it is 
necessary to define some minimum requirements on the scanning process. 

In order to find a CC the initial frequency scanning is performed first, e.g. if an H/2-HD is powered on. The CC 
selection process is started only in the case no CC has been found. 

A CC-capable device in the initial scanning phase shall: 

• Scan all available frequencies for other CC. 

• Scan each frequency for at least two MAC Frames = 4 ms. 

• Measure and store the interference level on all available frequencies. 

• Store all successfully received BCCH. 

• Decode the downlink RBCH, if a BCCH has been received successfully. 
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• Try association with all detected CCs. If a detected CC does not support the HE, the association with this CC 
shall be aborted. 

If association has been successful with any CC the CC selection for this CC-capable device is done. This device 
becomes a WT. 

If no BCCH has been detected, or no association has been successful the CC-capable device starts the CC collision 
resolution procedure, see clause 6.7.4. 

NOTE: An aborted association with a non HE-compliant CC is an unsuccessful association. The frequency used 
by this CC shall be excluded from the following CC collision resolution process. A re-association to this 
CC after the completion of CC collision resolution is optional, if no other CC with HE capability can be 
found, and the scanning CC-capable device decides not to become a CC. 

A manufacturer can implement on an H/2-HD different usage profiles. By selecting a non HE-compliant 
usage profile, the user can configure an H/2-HD as a non HE-compliant device to be preferably associated 
with a non HE-compliant CC. 

6.7.3 Definitions 



6.7.3.1 



Probing phase 



CC Probing Frame Fp 



BCCH 



/ TTA 

Start 
Transmission 

Figure 26: CC Probing frame 

Figure 26 shows a CC Probing Frame Fp. Within each CC probing frame a CC-capable device transmits one CC 
probing BCCH (for the contents of the Probing BCCH see clause 7.6). Inside Fp the beginning of the transmission is 
defined by the start_transmission time. Thus a CC probing BCCH can overlap into the next CC probing frame. This is 
shown in Figure 27. 



CC Probing Frame Fp 



CC Probing Frame Fp 



BCCH 



Next Start of Transmission 



/ TTA 

Start 
Transmission 



Figure 27: Start transmission of CC probing BCCH 



If the CC probing BCCH overlaps into the next CC probing frame, the next start of transmission is limited to the range 
from the end of transmission to the end of Fp. In Figure 27 this is called "next start of transmission". 
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6.7.3.2 Frequency scan phase 
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Figure 28: Probing period consisting of probing phase and frequency scan phase 

Figure 28 shows the definition of a Probing Period P. Each Probing Period consists of several CC Probing Frames 
(Probing Phase) and a Frequency Scan Phase. During the Frequency Scan Phase the CC Probing is stopped for the 
CC-capable device which performs the Frequency Scan. 

Within one Probing Period a CC-capable device shall scan all other frequencies for CC Probing BCCH. The Frequency 
Switching Time Tps is the maximum time it takes to switch to another frequency channel. This time is defined in the 
TS 101 475 [3]. The Frequency Scan Time TScan determines the time a CC-capable device in the CC Selection process 
shall scan a frequency channel for a CC Probing BCCH. The CC-capable device shall switch to a new frequency 
immediately after scanning the previous one. 

After a CC-capable device returns from a Frequency Scan Phase it continues with CC Probing Frames, if no BCCH has 
been detected during the Frequency Scan Phase. The definition and random calculation of the start time of the 
Frequency Scan Phase (timer Start_ Frequency_SCAN) per Probing Period is similar to the start time of the Beacon 
transmission (timer Start_Transmission) per CC Probing Frame. 



6.7.3.3 



Parameter, Timer 



Table 24: CC Selection Parameters 



Parameter 


Value 


CC Probing Frame Fp 


500 ns 


Frequency SCAN Time TScan 


2 X Fp = 1 ms 


CC Probing Period P 


100 ms 


Number of Periods 


10 


Total Time for CC Collision Resolution 


1 s 


Collision Probability 


5x10"'' = 0,005%= 1/20 000 



The Timer for Start Transmission and Start Frequency SCAN are set as follows: 
Start Transmission: 

• Start_Transmission is randomly chosen with a uniform distribution within [min_Start_Transmission, 
CC_Probing_Frame Fp); 

• min_Start_Transmission = max (0, previous_Start_timeH-BCCH_Transmission_duration - Fp); 
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• previous_Start_time = for the first transmission in the first Probing Period and after each Frequency Scan 
Phase; 

• previous_Start_time = Start_Transmission, after the selection of Start_Transmission; 

• BCCH_Transniission_duration = 48 )is (including preamble and two transceiver tumaround times). 
Start Frequency SCAN: 

• Start_Frequency_SCAN is randomly chosen with a uniform distribution within [min_Start_Frequency_SCAN, 
Period P); 

• min_Start_Frequency_SCAN = max (0, 
previous_Start_Frequency_SCAN_time+Frequency_SCAN_duration - P); 

• previous_Start_Frequency_SCAN_time = for the first frequency Scanning Phase; 

• previous_Start_Frequency_SCAN_time = Start_Frequency_SCAN, after the selection of 
Start_Frequency_SCAN; 

• Frequency_SCAN_duration = 37 ms (for a total number of 18 available frequency channels - the Probing 
Channel is excluded - and a frequency switching time of 1 ms TS 101 475 [3]. 

6.7.4 Protocol 

If no Association has been successful the CC-capable device shall choose one appropriate frequency channel. This 
frequency channel is called CC Probing frequency. 

The CC-capable device shall: 

• Maintain a CC Probing Frame timer. 

• Maintain a Start_Transmission timer. 

• Maintain a CC Probing Period timer. 

• Maintain a Start_Frequency_SCAN timer. 

• Maintain a Period counter. 

• Select a CC Probing BCCH transmission start time (Start_Transmission) each time the CC Probing Frame timer 
expires, or after the completion of the Frequency Scan Phase, if no BCCH has been detected; Set the CC Probing 
Frame Timer to Fp. 

• Select a frequency scanning start time (Start_Frequency_SCAN) each time the CC Probing Period timer expires, 
set the CC Probing Period Timer to P and increase the Period_Counter by one. 

• Transmit a CC Probing BCCH, if the CC Probing BCCH transmission start time is reached. 

• Stop CC Probing and Start the frequency scanning procedure, if the frequency scanning start time is reached. 

• Sense each frequency channel excluding the last Probing Frequency for other Probing BCCH. 

• Stop the CC Selection Procedure and start a back-off of (1 s), if a Probing BCCH or a regular BCCH is received 
successfully. All timers are stopped. After the back-off has expired the CC-capable device starts again with the 
initial scanning process trying to find a CC in operation and to associate to it, see clause 6.7.2. If no association 
is possible the CC Selection Protocol is performed again. 

• Start CC operation, if Period_Counter = Number of Periods. 
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6.7.4.1 Frequency scanning 



During the frequency scanning each frequency channel except the CC Probing frequency channel is scanned for CC 
Probing BCCH. The order of the frequency channels is randomly chosen. The selection procedure has to ensure that 
each frequency is scanned once per Frequency SCAN. 

Each frequency is scanned for 1 ms. If no BCCH has been detected after 1 ms the CC-capable device switches to the 
next frequency. If no more frequencies have to be scanned in the current Period, the CC-capable device continues with 
CC Probing Frames. 

6.8 CC Responsibility Handover (OCC/OWT) 

The CC Responsibility Handover is necessary in case that the current CC is no longer able or intended to carry the CC 
responsibility for the subnet. Reasons for a CC Responsibility Handover, that are out of the scope of the present 
document, can be e.g. switch off of the WT currently carrying the CC responsibility, a bad connectivity of the current 
CC, power constraints of the CC, etc. Only old CC-initiated CC Handover is considered in the present document. 

The CC Responsibility Handover protocol guarantees a soft handover, in which case all DiL connections are maintained 
during and after the handover process. The handover is transparent to the network and to the other WTs as far as DiL 
connections are concerned. The same applies to the user plane of the two terminals involved in the CC Responsibility 
Handover. The old CC becomes a WT and keeps its own DiL connections. All connections in CM are nevertheless 
released during CC Responsibility Handover. The CC Responsibility Handover concerns mainly MAC control and RLC 
instances of the control plane of the current CC. 

To seamlessly maintain all running DiL connections, the RLC instances of the current CC have to be transferred to the 
CC-capable WT that is going to take over the CC responsibility. This CC-capable WT is called CC-candidate. All 
relevant RLC information is directly transmitted from the current CC to the CC-candidate. This is done during ongoing 
operation on the current frequency. No MAC control information is transferred during or after the CC Handover 
process. The new CC may build its own MAC database by either listening to RRs of the WTs and decoding RGs in the 
frames before CC Handover or by polling the WTs for RRs in the frame(s) after CC Handover. After successful 
preparation of the CC Handover between the old and the new CC, the new CC takes over BCCH transmission 
seamlessly. 

Support of CC Responsibility Handover is optional for CC-capable H/2-HDs. 
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6.8.1 Basic procedure 

The basic procedure of CC Responsibility Handover can be depicted from Figure 29. 



CC Handover Initiation 



Request to CC-candidate 



Inform all WTs about forthcoming CC Handover 



Stop RLC 



Inform CLs which prepare for CC Handover 



Transfer RLC Data to CC-candidate 



Instruct CC-candidate to start BCCH transmission 



Inform CLs and other WTs about successful Handover 



Figure 29: Basic Procedure of CC l-landover 

In case of a CC initiated CC Responsibility Handover the handover procedure is triggered by an internal request. 

• As the CC Handover should be as much as possible transparent to the higher layers the CC Handover is triggered 
by an implementation specific algorithm inside the RLC layer. This is indicated by the CCH_cc_ho_request_req 
primitive which is generated under control of the RLC (see Figure 30). 

After reception of the CC Handover Request the current CC has to select a CC-candidate from the list of CC-capable 
WTs. As an example, this selection can be done based upon the global connectivity map, see clause 6.5.4. 

The selected CC-candidate HL2/HD is informed, that it has been chosen to take over the CC functionality. This implies 
the following message exchanges: 

• A Handover Request message is sent out to the selected CC-Candidate. The selected CC-candidate is requested 
to prepare itself for the CC Handover. RLC_CC_HO_REQUEST is transmitted on DL DCCH. 

• The CC-candidate informs its RLC environment about the CC Handover Request by a CC Handover Indication. 

• The RLC environment of the CC-candidate answers with a CC Handover Response. 

• Then the selected CC-candidate WT acknowledges that it is prepared for the CC Handover. This 
RLC_CC_HO_ACK PDU is transmitted on UL DCCH. 
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The next step consists in informing all WTs about the forthcoming CC Handover. Sleeping WTs are not woken up. 
Instead, the sleeping intervals of these WTs are transferred together with the other RLC data to the CC-candidate in a 
later stage of the procedure (see below). 

• The CC sends out a broadcast message on DL RBCH to inform all WTs about the forthcoming CC 
Responsibility Handover (RLC_CC_HO_NOTIFY). Even CC Handover is optional for CC-capable devices, the 
RLC_CC_HO_NOTIFY shall be supported by all H/2-HDs. 

In response, the RLC entities of all WTs in the subnet are stopped. This means that no new Association, DUC 
Set-up/modify /release, power saving and DFS requests are started. The RLC entities of the WTs are set into a special 
state RLC_Stopped_WT which only occurs during CC Handover. 

• At the same time all ongoing Association, DUC Set-up/modify/release and power saving requests are aborted by 
the current CC. 

The RLC entities within the CC are set into the RLC_Stopped state. New requests are not processed by the CC any 
more. During CC Handover no Association, DUC Set-up/Modify, Sleep or DFS request is possible to ease the 
operation. However RLC_INFO requests (either MT or CC initiated) shall be possible during a CC Handover operation. 

The fifth step in Figure 29 concerns the influence of the CC Handover on the higher layers, which may have to prepare 
for the CC Handover. 

• After the positive acknowledgement of the CC-candidate the current CC sends out a CCH_start_cl_ho_ind 
primitive to the environment. This primitive may be used by the CLs as information of the forthcoming CC 
Handover. 

After reception of the CCH_start_cl_ho_ind the CLs may prepare themselves for the CC Responsibility Handover, if 
this is necessary. They may e.g. perform a CL handover, if the current CC also contains a centralized decision making 
entity and database in the respective CL. It is up to the CLs of the old CC to inform the other WTs (including the 
CC-candidate) on CL level about the ongoing CC Handover on RLC level, if necessary. The main part of the CC 
Handover procedure on RLC level, the transmission of the RLC data to the CC-candidate, may not be started unless the 
CL procedures are finished. 

• After a CCH_start_cl_ho_rsp primitive is received from the environment, all connections in CM are released by 
the CC. 

DiL connections relayed by the current CC are kept. They are only released in case that the CC is leaving the network 
(e.g. switch-off). 

• Then the transfer of data, states and timers of the RLC to the CC-candidate is started by a CCH_start_cc_req 
primitive from the RLC environment. For this purpose DL DCCH is used between the CC and the CC-candidate 
(ordinary RLC operation). The RLC instances in the new CC are set to the same state as in the old CC. For a 
detailed description of the data transfer see clauses 6.8.3 and 7.8. 

• The CC data PDUs are transmitted by means of a "Go-back-n" ARQ mechanism. A certain number of 
RLC_TRANS_CC_DATA PDUs are acknowledged by the CC-candidate with a 
RLC_TRANS_CC_DATA_ACK PDU on UL DCCH. 

The CC-candidate is now ready to take over the CC functionality. To enable a smooth handover, the old CC informs the 
new CC when to start with a BCCH transmission. This is done by a handshake message. 

• The current CC sends a RLC_START_CC message to the CC-candidate using DL DCCH and including an 
indication when to start with BCCH transmission (start-mac -frame). The parameter start-mac-frame gives the 
exact MAC Frame the new CC shall start CC operation, start-mac-frame is the absolute MAC Frame number as 
determined by the MAC Frame Counter in the BCCH. To overcome the 4 bit limitation of the MAC Frame 
Counter parameter in BCCH, Start MAC Frame is furthermore offset by a MAC Frame Cycle parameter, which 
gives the number, the MAC Frame Counter value repeats in BCCH after the reception of the Start CC message 
(1 repetition corresponds to 16 MAC frames). The reference for the offset is the MAC frame the RLC_Start_CC 
PDU is received. That means that the RLC instance shall know in which MAC frame it received the 
RLC_Start_CC in order to determine the right MAC frame to start CC operation. The CC-candidate shall be able 
to start the CC operation at latest 2 MAC frames after the arrival of the RLC_Start_CC message. 
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Start-mac -frame is 16 bits long. Its 4 MSB are used to encode the MAC Frame Counter value, and its 12 LSB are used 
to encode the MAC Frame Cycle value. Either coding is in binary. With this length of the start-mac-frame parameter the 
maximum time between the RLC_START_CC PDU and the CC Handover is 131 s. 

EXAMPLE: start-mac-frame = 00 1 00000000000 1 

The MAC frame to start CC operation is the second time (because of offset = 000000000001) the 
MAC Frame Counter in the BCCH shows the value 0010 after the reception of the RLC_Start_CC 
PDU. 

• The CC-candidate sends a CCH_start_cc_ind primitive to the environment. This primitive may be used to inform 
the CLs present in the CC-candidate about the completion of the CC Handover. 

• Upon reception of a CCH_start_cc_rsp the CC-candidate sends a RLC_START_CC_ACK message to the old 
CC using UL DCCH. 

The new CC starts at the time a BCCH is expected. Thus the synchronization is nearly maintained (apart from some 
jitter due to the ±20 ppm BRAN clock drift in old and new CC). The new CC shall use maximum transmit power in the 
first frames after take over of the CC responsibility. When the new CC is ready to take new RLC requests, it enables the 
RLC instances again. 

• The new CC informs the WTs about the successful CC Responsibility Handover by sending out a 
RLC_CC_START_0PERAT10N Broadcast message on DL RBCH. On reception of 
RLC_CC_START_0PERAT10N the WTs are allowed to start again with new RLC requests. Even CC 
Handover is optional for CC-capable devices, the RLC_CC_START_0PERAT10N shall be supported by all 
H/2-HDs. Both CC and WTs may apply an increased power level after reception of the 
RLC_CC_START_0PERAT10N (because the distance to the CC has changed). 

• At the same time the old CC, which knows the start time of the new CC, informs its RLC environment about the 
take over of the CC responsibility by the new CC using a CCH_start_cc_cnf. 

NOTE: Like for all other procedures, the primitives (between RLC environment and RLC as well as between CLs 
and RLC) defined in this clause are only of informative nature. 

The RRs, or the state of the scheduler are not transmitted to the new CC. Thus the new CC has to take action to get RRs 
from the WTs. The new CC can either listen to RRs and decode RGs in the frames after the first Handover Request 
message and already before sending out the BCCH for the first time or it can poll WTs in the frame(s) after take over of 
the CC responsibility. 

During the whole CC handover process, the ordinary user data transmission including RR, RG, scheduling. Random 
Access, and Random Access Feedback go on as usually for all DiL connections. 

A high level Message Sequence Chart (MSC) of the CC Handover Procedure can be found in Figure 30. 
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MSC CC Handover 



CC ENV 



CC RLC 



CC CAND RLC CC CAND ENV 



WTs ASSOCIATED TO OLD CC 



CCH_cc_ho_request_req 



T_cc_ho_request_c(; 



(mac-id) 



RLC 



C(DH_cc_ho_request_cnf 



(mac-id) 



RLC CC HO REOUEST 



CC H_cc_ho_request_i nd 



(mac-id) 
C;CH_cc_h o_requ est_rsp 



3C_H0_REQUEST_ACK 



(mac- id) 



RLC CC HO NOTIFY 



Stop_RLC 



CC_abort_all_ongoing_RLC_requests 



CCH start cl ho ind 



CLs_prepare_for_CC_HO 

CCH_start_cl_ho_rsp 



CC Release all UL and DL connections 



CCH_start_cc_req ^ rlc_TRANS_CC_DATA 



(mac-id) 
trans cc data cc 



(ext-ind, data) 



RLC TRANS_CC_DATA_ACK 

M 

/ (sn, rr-flag) 

RLC START CC 



T start cc cc 



CCH start cc cnf 



(start-mac-frame) 



RLC START CC ACK 



CCH_start_cc_ind 

►- 

(mac-id, start-mac-frame ) 

CCH_start_cc_rsp 

•9 

(mac- id) 

RLC CC START OPERATION 



(mac-id) 



Reable RLC 



WTs ASSOCIATED TO NEW CC 



WT RLC 



Figure 30: MSC of the CC Responsibility l-landover Procedure 
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Table 25: RLC TRANS CC DATA 





RLC-TRANS-CC-DATA-ARG : 


:= SEQUENCE{ 


ric-pdu-type 


RLC-HE-SCH-PDU-TYPE 




extension-type 


EXTENSION-TYPE, 




ext-ind 


EXT-IND, 




data 


DATA} 





Table 26: RLC TRANS CC DATA ACK 



RLC-TRANS-CC-DATA-ACK-ARG : := SEQUENCE{ 



ric-pdu-type 
extension-type 
sn 

rr-flag 
J 



RLC-HE-SCH-PDU-TYPE 
EXTENSION-TYPE, 
SEQUENCE-NUiVIBER 
RR-FLAG 



Table 27: RLC START CC 



RLC-START-CC-ARG::= SEQUENCE{ 



ric-pdu-type 
extension-type 
start-mac-frame 
J 



RLC-HE-SCH-PDU-TYPE 

EXTENSION-TYPE, 

START-MAC-FRAiVIE 



6.8.2 RLC Data transmitted during CC Responsibility Handover 

The data to be transmitted from the current CC to the CC candidate falls into two categories: 

• parameters related to all associated H/2-HDs; 

• parameters related to all maintained DiL connections (unicast and multicast). 

No information related to connections in CM shall be transmitted, because these connections are not maintained 
during CC Handover. 

No broadcast specific parameters shall be transmitted, because the CC-candidate has necessarily been member of the 
broadcast group. 

No CC specific parameters shall be transmitted during CC Handover. This is due to the fact that relevant parameters 
like NET ID or AP ID of the old CC are always announced in the BCCH and therefore known to the CC-candidate. The 
new CC takes over the AP ID of the old CC, but all MAC IDs remain unchanged. 

No RR specific parameters shall be transmitted during CC Handover. The reason for this is that all RR specific 
information is related to the same frame, in which this information is transmitted from the old to the new CC. In other 
words, this information is already quite old if the new CC receives it. Another reason for not transmitting the RRs from 
the old to the new CC is, that the probability of error in this transmission is as high as the probability that the 
CC-candidate does not correctly understand a RR, if the CC-candidate is listening to the RRs in the frame(s) before the 
handover. 

If the CC-candidate was not able to listen to the RRs in the frames before handover, there is an interruption from the 
user point of view in the "loss" of RRs. If the new CC polls all WTs in the first MAC frame for RRs by granting one 
LCCH to each WT and connection, the interruption is limited to one MAC frame. 
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6.8.2.1 



Parameters related to all associated H/2-HDs 



For every WT as well as for the old CC (which becomes a WT) the following set of parameters (Table 28) should be 
transmitted. 

Table 28: Parameters related to all associated H/2-HDs 



Parameter 


0/M 


Description 


auth-id-pr 


M 


One bit that equals 1 if mt-auth-id is transmitted (resp. present). 


mt-auth-id-type 





The mt-auth-id (4 bits) is of one of the following types: 

ieee, ext-ieee, net-acc-id or dist-name, compressed or generic. 


mt-auth-id 





This is the concrete authentication identifier of the H/2-HD in one of the formats 
mentioned above. It is either 6 octets long in case of an ieee address, 8 octets long in 
case of ext-ieee, 46 octets long in case of net-acc-id or dist-name, 16 octets long in 
case of "compressed" and 92 octets in case of "generic". 


mac-id 


M 


This is an 8 bits long unique identifier of the H/2-HD inside one subnet. 


dic-version-selected 


M 


Version of the DLC protocol (8 bits long). 


ric-version-selected 


M 


Version of the RLC protocol (8 bits long). 


nr-cl-vid 


M 


Indicates the number N of CLs present within the H/2-HD and at the same time the 
number of cl-vid that follow. The nr-cl-vid field is 3 bits long. 


cl-vid 


M 


This parameter consists of a cl-id field (8 bits) and a cl-version field (8 bits), which 
define the id and version of one of the multiple CLs. For every CL present within the 
H/2-HD the cl-vid parameter is transmitted. 


support64qam 


M 


One bit that equals 1 if WT supports 64 QAIVI. 


freq-band 


M 


Identifies which frequency band can be used by the WT. Low band: 5 180 MHz 
to 5 320 MHz. High band: 5 500 MHz to 5 700 MHz. (2 bits). 


direct-mode-cap 


M 


One bit that equals 1 if WT supports DM. 


support-fca 


M 


One bit that equals 1 if WT supports polling. 


support-fsa 


M 


One bit that equals 1 if WT supports FSA. 


ho-cap 


M 


1 bit that indicates if WT is handover capable. 


cc-ho-cap 


M 


1 bit that indicates if WT is CC Handover capable. 


duty-cycle 


M 


percent of the MAC frame that the WT can use for uplink transmission (3 bits). 


cyclic-prefix 


M 


1 bit to indicate the type of the preamble used by this H/2-HD. 


time-gap-ach-uplink 


M 


Indicates time the respective H/2-HD needs after FCCH reception until it can receive 
again (3 bits). 


arq-delay-rx 


M 


ARO delay of the receiver inside the respective H/2-HD (2 bits). 


arq-delay-tx 


M 


ARO delay of the transmitter inside the respective H/2-HD (2 bits). 


auth-encr-selected 


M 


This parameter consists of an auth-info field and an encr-info field, which are 4 bits 
long each and define the type of auth. and encr. selected. 


dll-power-control 


M 


2 bits to indicate the type of DiL power control. 


tx-arq-win-size 


M 


3 bits for window size. 


rx-arq-win-size 


M 


3 bits for window size. 


length-of-measurement 


M 


Indicates how many MAC frames the WT will still be absent for DFS. Reference frame 
is the frame in which this parameter is transmitted during CC Handover. A 
start-of-measurement parameter is not necessary, since the length-of-measurement 
field should be filled (in case of CC Handover) with the remaining absence time of the 
WT and since a start-of-measurement value in the future would not be possible, 
because the RLC is stopped during CC Handover. Afterwards, the new CC is 
responsible for polling the WT that is not aware of the CC Responsibility Handover 
due to its absence for DFS. The field is 6 bits long, 
length-of-measurement is set to if the WT is not absent for DFS. 


sleep-interval 


M 


Indicates how many MAC frames the WT will still be sleeping. Reference frame is the 
frame in which this parameter is transmitted during CC Handover. A fc-start-pointer 
parameter is not necessary, since the sleep-interval field should be filled (in case of 
CC Handover) with the remaining sleeping time of the WT and since a fc-start-pointer 
value in the future would not be possible, because the RLC is stopped during CC 
Handover. Afterwards, the new CC is responsible for polling the WT that is not aware 
of the CC Responsibility Handover, because it has been in sleeping mode during the 
procedure. Sleep time is 22sleep-interval (s bits), 
sleeping-interval is set to if the WT is not in sleeping mode. 


cl-common-attr-length 


M 


5 bits to indicate the length of the cl-common-attr container. 


cl-common-attr 


M 


This field represents a container in which CL related information is transferred that is 
common to all DUCs of the respective H/2-HD. The length M of the container can vary 
between octet and 31 octets in multiples of one octet. 
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Parameter 


0/M 


Description 


nr-mc-groups 


M 


Indicates the number L of DM multicast groups the H/2-HD is participating in and at 
the same time the number of group-mac-id fields that follow. The nr-mc-groups field is 
5 bits long. 


first-group-mac-id 


M 


Multicast Group MAC ID of the first group the H/2-HD is member of (8 bits). 


second-group-mac-id 


M 


Multicast Group MAC ID of the second group the H/2-HD is member of (8 bits). 


(until L*-group-mac-id) 


M 





For operation in a single HEE subnet MT-AUTH-ID is not absolutely necessary. Inside the subnet the MAC ID is 
already a unique identifier of the H/2-HD. This is why the transfer of the parameters mt-auth-id-type and mt-auth-id is 
only optional. The flag auth-id-pr, which indicates the presence of the MT AUTH ID during transmission, is 
nevertheless mandatory. 

NOTE: The information regarding DiL multicast groups is implicitly contained in this set of H/2-HD-specific 
parameters. 

The ASN.l tables of the parameters can be found in TS 101 761-2 [2], except for mit-id-pr, auth-id-pr, nr-cl-vid, 
cl-common-attr-length, nr-mc-groups, first-group-mac -id and second-group-mac-id, etc. The mt-id-pr, auth-id-pr, 
nr-cl-vid and the nr-mc-groups parameters are new and have the length and purpose described above. The group-mac -id 
fields are parameters, only transmitted during CC Handover, but are of the same type as mac -id. The 
cl-common-attr-length is also a new field which has the same type as the cl-conn-attr-length in TS 101 761-2 [2]. 

Beside the H/2-HD specific data, the data regarding the DiL connections of each H/2-HD has to be transmitted in 
addition. These parameters are treated in the following clause. 



6.8.2.2 



Parameters related to all maintained DiL connections 



Parameters related to DiL unicast connections on the one hand side and parameters related to DiL multicast connections 
on the other hand can be treated in a very similar way. Table 29 shows the parameters that shall be transmitted for each 
DiL unicast or multicast connection. 

Table 29: Parameters related to all maintained DM connections 



Parameter 


0/M 


Description 


first-mac-id 


M 


In case of a DiL unicast connection first-mac-id (8 bits) is filled with the mac-id of one 
of the two H/2-HDs involved in the connection. In case of a DiL multicast connection 
the first-mac-id field is filled with the mac-id of the sending H/2-HD. 


second-mac-id 


M 


In case of a DiL unicast connection second-mac-id (8 bits) is filled with the mac-id of 
the other of the two H/2-HDs involved in the connection. In case of a DiL multicast 
connection the second-mac-id field is filled with the mac-id of the multicast group for 
which the connection is maintained. 


cl-vid 


M 


This parameter consists of a cl-id field (8 bits) and a cl-version field (8 bits), which 
define the id and version of one of the multiple CLs. For every CL present within the 
H/2-HD the cl-vid parameter is transmitted. 


dicc-id 


M 


Connection Identifier (6 bits). In case of a multicast connection the dIcc-id is always set 
to the value 63. 


direction 


M 


2 bits to indicate in case of a unicast connection one of the following four possibilities: 

simplex-forward, simplex-backward, duplex, duplex-symmetric. 

In case of multicast the connection is always of type simplex-forward. 


cl-conn-attr-length 


M 


Length of the cl-conn-attr(ibutes). Not all cl-attributes containers of all connections 
have the same length. Field is 5 bits long. 


cl-conn-attr 


M 


Container for CL specific information of the respective connection. The length of the 
container can vary between octet and 31 octets in multiples of one octet. 


forward-descr 


M 


Forward descriptor of the connection (56 bits in total). It comprises the following fields: 
allocation-type, cyclic prefix, ec-mode, arq-used, fee-used, arq-data, fee and fca-descr. 


backward-descr 


M 


Backward descriptor of the connection (56 bits in total). It comprises the same fields as 
the forward-descr (see above). In case of a multicast connection no backward-descr is 
present, which is indicated by the direction field being set to "simplex-forward". 



The ASN.l tables of the parameters can be found in TS 101 761-2 [2]. First-mac-id and second-mac -id are of the same 
type as peer-mac -id in TS 101 761-2 [2]. 
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6.8.3 Data transfer procedure 



The parameters related to all associated H/2-HDs and the parameters related to all DiL connections are transmitted as 
byte string from the CC to the CC-candidate. The structure of this byte string and the coding of the parameters inside 
the byte string are defined in clause 7.8. The byte string is transmitted as payload of one or several DiL DCCH LCHs 
called RLC_TRANS_CC_DATA PDUs. The coding of a RLC_TRANS_CC_DATA PDU is also defined in clause 7.8. 

If the byte string has to be transmitted on several RLC_TRANS_CC_DATA PDUs, it has to be segmented. The 
complete byte string shall be reassembled in the receiver. To reassemble the payload of the RLC_TRANS_CC_DATA 
PDUs in the correct order, each PDU shall have a Sequence Number (SN). For this purpose the SN-field defined in 
TS 101 761-1 [1] shall be used. This is possible because the field is in general not used in case of a DiL DCCH. 

To ensure the integrity of the transmitted data, a "Go-back-n" ARQ mechanism shall be applied on the 
RLC_TRANS_CC_DATA PDUs using RLC_TRANS_CC_DATA_ACK PDUs. The sender window is implicitly 
defined by the size of the SN-field (1 024 PDUs). 

NOTE 1: It is implementation specific and e.g. load dependent, how many RLC_TRANS_CC_DATA_PDUs are 
transmitted before the sender (CC) waits for a RLC_TRANS_CC_DATA_ACK sent by the receiver 
(CC-candidate). 

With a RLC_TRANS_CC_DATA_ACK PDU the receiver acknowledges all PDUs up to an indicated SN-1. A 
ReceiveReady-flag (RR-flag) inside the RLC_TRANS_CC_DATA_ACK indicates whether further PDUs (starting with 
SN) have not been correctly received (RR - flag = 0) or whether all PDUs up to (and including) SN have been correctly 
received (RR - flag = 1). In the first case the sender (CC) shall re-send all PDUs beginning with the indicated SN. 

NOTE 2: In the second case the acknowledged SN may be lower than the SN of the last sent PDU. This may occur 
if the receiver (CC-candidate) has not yet processed the remaining PDUs. Nevertheless, the sender (CC) 
shall continue transmission of RLC_TRANS_CC_DATA PDUs beginning with SN where he had 
previously stopped transmission. 

If the sender (CC) has not received a RLC_TRANS_CC_DATA_ACK PDU within time T_tmns_cc_data_cc, it shall 
re-send all RLC_TRANS_CC_DATA PDUs from the last acknowledged SN on. The receiver (CC-candidate) shall send 
at least one RLC_TRANS_CC_DATA_ACK PDU per frame (if there are RLC_TRANS_CC_DATA PDUs that have 
not yet been acknowledged). 

The timer T_trans_cc_data_cc shall be set to 6 ms. 

6.9 Authentication key management (OCC/OWT) 

During association, the authentication phase may be performed by a challenge/response technique in which each 
end-entity (CC and WT) uses a common secret authentication key to respond to the challenge sent by the other entity. 
Home devices shall use the key of type AUTH-KEY defined as OCTET STRING (SIZE(0..36)). A procedure is 
specified how to download the authentication key into each H2-HD. During authentication this key will be used as a 
generic content of the MT-AUTH-ID as defined in TS 101 761-2 [2] (also an OCTET STRING but allowing for larger 
size). 

Before an H/2-HD can take part in normal operation, meaning to start the CC selection process as a CC-capable device, 
or to start the association process as a basic WT, it shall first be initialized with the common secret authentication key 
and the owner identifier NET-ID of the home network, auth-key and NET-ID shall only be generated by the first 
CC-capable device to be installed in the home network and shall then be distributed to each new device to be installed. 
The NET-ID is broadcast by the CC in the BCCH and therefore known to every WT to be installed. The new WT shall 
store the NET-ID locally. The authentication key auth-key is distributed in a secure way to avoid: 

• the key to be discovered by an eavesdropper; 

• the registration of an attacker's devices on a network. 

To avoid the registration of attacker's devices on a home network, each network shall be protected by an up to 10 octets 
PIN (Personal Identification Number). This PIN shall be stored in the CC (or each CC-capable device). When installing 
a new device, the user shall be asked via an implementation specific user interface whether: 

1) the device is the first device to be installed in the network; 
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2) the device is a new additional device in the network (in that case, another device shall already have been 
installed in the network). 

In the first case, the CC capable device to be installed shall act as a CC without performing CC Selection, and shall 
generate the secret auth-key and the owner identifier NET-ID. In the second case, the new device to be installed shall 
act as a WT without performing CC Selection; the existing CC broadcasts NET-ID and shall send auth-key to this new 
device. 

The PIN is CC-defined and a way of recovery may exist in case the PIN is lost. This way may be different for each 
manufacturer and is out of the scope of the present document. Moreover, a user may have the ability to change his PIN. 

6.9.1 Installation of the first device in the network 

Using an implementation specific interface, the user shall be asked if the device to be installed shall be the first 
operational device of a network. The first device of a network shall be CC-capable. To avoid wrong setting by the user, 
the device may indicate to the user if it has detected other CCs with or without displaying the associated NET-IDs. If 
the user set the device as the first device in the network, the device shall act as the CC on a free frequency and shall 
generate the secret key auth-key and the owner identifier NET-ID. Before generating them, the CC inquire the 
network's PIN from the user. If the PIN is validated by the CC, the CC generates auth-key and NET-ID. 

auth-key shall be the output of a random generator, or the result of a function/that depends on several parameters such 
as the device identifier, the network PIN and so on: 

auth-key = f(device_id, PIN,. . .). 

The function/shall ensure the approximate uniqueness of auth-key. This means that given two different possible inputs 
of/, the probability of obtaining the same key auth-key shall be less than 2'^^. However, /may be different for each 
manufacturer and its definition is out of the scope of the present document. 

NET-ID shall be a random number between and 959. During the installation and normal operation, the NET-ID shall 
be sent on BCCH by the acting CC. 

The user shall be able to undo or renew this first device installation process whenever he/she wants. 

NOTE: The manufacturer should make clear in the user manual that the user should not configure a new 
CC-capable device as the first one, if there is already one installed. 

If multiple CC-capable devices are configured by the user as the first devices of a network. It is very 
likely that they generate independent networks with different owner identifiers and authentication keys. 

By looking at an implementation specific indicator on each CC-capable device, the user should be able to 
detect if more than one CC is active at a time. If the user wants to have one single network, he/she should 
undo the installation process of all CCs, except the one that he/she wants to keep. 

6.9.2 Installation of a new device in the network 

The generated authentication key auth-key shall be downloaded into each new device before it can use the network. 
This download phase involves the participation of the CC and the new H2-HD, and is composed of the following steps: 

1) via an implementation specific user interface, the user shall activate the installation phase on the CC to install a 
new device; 

2) the CC shall inquire the network PIN from the user. If the entered PIN is validated by the CC, the download 
process is started and remains valid during a time window; The user may determine the duration of the time 
window; 

3) the user shall activate the installation phase on the new H2-HD to be installed. This device shall associate with 
the CC, requesting unicast encryption but no authentication. At the end of this association phase, the H2-HD 
and the CC agree on an encryption algorithm A (A may be DES or 3DES) and execute a Diffie-Hellman key 
exchange. The result of this step is a secret session key SSK shared by the new device and the CC. This session 
key shall be used by the algorithm A negotiated in the previous step. Figure 3 1 gives an overview which parts of 
the association procedure are carried out for the installation purpose. 



£75/ 



71 



ETSI TS 101 761-4 VI .3.2 (2002-01) 



< 



1 



MT_DISASSOCIATED_FROM_AP 



Z^ 



RBCHAssociation 



RBCHAssociation 
_Request 



^ 



-o- 
_L 



^ 



MAC_ld_Assignment 



L 



I 



LinkCapability 



EncryptionStartup 



I 



I Authentication I 



DM_Common_Key_ 
Distribution 



^ 



Info Transfer 



J 



<) 



-0 



■o 



IVIT ASSOCIATED TO AP 



A 



Figure 31 : Association procedure for installation purposes 

4) After association, the new device shall give its identification number mt-id-number to the CC. The length of 
identification number is limited to 47 octets. The definition of the identification number is out of scope of the 
present document; 

5) The CC shall display the information of the new device (identification number) to the user and ask for 
validation; 

6) If the user validates, auth-key and the network's PIN are sent to the new device, encrypted by the algorithm A 
using the key SSK. As the length of auth-key and the PIN are not prescribed, two length-fields are also included 
in the PDU. At receipt, the device stores K, together with the NET-ID received on BCCH, in a non-volatile 
memory and sends the acknowledgement SSK(MD5(K)) to the CC; 

7) The new device disassociates and starts a normal association requesting encryption and authentication. 

NOTE 1: In order that the user can validate the identification number mt-id-number, it is to be displayed on the new 
device and the CC in the same format to be agreed upon by manufacturers. 
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These steps are illustrated in Figure 32. 
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Figure 32: Messages exchanged during thie installation of a new device 
Table 30: RLC-AUTHENTICATION-KEY-REQUEST 



RLC-AUTHENTICATION-KEY-REQUEST-ARG: 


:= SEQUENCE! 


ric-pdu-type RLC-HE-LCH-PDU-TYPE, 




extension-type EXTENSION-TYPE, 




mt-id-number-length MT-ID-NUMBER-LENGTH, 




mt-id-number MT-ID-NUMBER } 
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Table 31 : RLC-AUTHENTICATION-KEY-REQUEST-ACK 



RLC-AUTHENTICATION-KEY-REQUEST-ACK-ARG::=SEQUENCE{ 



ric-pdu-type RLC-HE-SCH-PDU-TYPE 

extension-type EXTENSION-TYPE, 

J 



Table 32: RLC-AUTHENTICATION-KEY-TRANSFER 



RLC-AUTHENTICATION-KEY-TRANSFER-ARG : := SEQUENCE{ 


rIc-pdu-type 


RLC-HE-LCH-PDU-TYPE, 


extension-type 


EXTENSION-TYPE, 


valid-l<ey 


VALID-KEY, 


- 


indicated whether the exchanged 


- 


key is valid or not 


auth-l<ey-lengtli 


AUTH-KEY-LENGTH, 


pin-code-lengtii 


PIN-CODE-LENGTH, 


auth-l<ey 


AUTH-KEY, 


pin-code 


PIN-CODE} 



Table 33: RLC-AUTHENTICATION-KEY-TRANSFER-ACK 



RLC-AUTHENTICATION-KEY-TRANSFER-ACK-ARG: 


:= SEQUENCE{ 


rIc-pdu-type RLC-HE-SCH-PDU-TYPE, 




extension-type EXTENSION-TYPE, 




valid-key VALID-KEY, 




- indicated whether the exchanged 




- key is valid or not 




md5-of-auth-key MD5-0N-KEY} 





To download the common authentication key and the owner identifier from the CC, the new device shall first run an 
association phase without the authentication procedure. It shall abort this association, as soon as it detects that the CC to 
be associated with is a Non HE-compliant Device. If more than one active HE-compliant CCs are detected, the new 
device to be installed shall try out the CC, whose download process has been started by the user. When the 
authentication key has been exchanged, the WT shall disassociate and run the association procedure with the 
authentication phase. 

NOTE 2: The installation phase activation mentioned in steps (1) and (3) depends on the manufacturers and is out 
the scope of the present document. Moreover, the choice of algorithm A in step (3) depends on the 
required security level. The standard does not impose any algorithm but recommend to use 3DES to reach 
a high level of security. 

Three new RLC messages are introduced, namely RLC_AUTHENTICATION_KEY_REQUEST, 
RLC_AUTHENTICATION_KEY_TRANSFER, RLC_AUTHENTICATION_KEY_TRANSFER_ACK. The encoding 
of these RLC PDUs is defined in clause 7.9. 

Once a H2-HD is installed, it can be reinstalled in any new network by repeating the eight operations mentioned above 
on the new network. In that case, the old authentication key may be deleted and replaced by the new one, if the 
manufacturer only supports one usage profile. Using an implementation specific user interface, the user may be enabled 
to select different usage profiles. Different usage profiles may correspond to different independent networks in the same 
or different places. In this case, for each usage profile a specific authentication key and owner identifier can be 
downloaded and stored in the H/2-HD. 
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RLC Protocol Data Units 



7.1 



General 



The general concept of the transfer syntax of RLC is described in TS 101 761-1 [1] and TS 101 761-2 [2]. The 
definition of MSB for coding of RLC messages and its usage rules are given in TS 101 761-2 [2] (clause 4.4). 

7.2 Terminal association for multiple convergence layers 

The terminal association consists of the MAC_Id assignment, the link capability, the encryption startup, the 
authentication and the information transfer procedure. Only the RLC PDUs for link capability exchange and the 
information transfer carry information, which is needed for the multiple convergence layers association. For the 
corresponding message formats, parameters and their values please refer to clause 6.2. 

For each convergence layer negotiated by WT and CC an RLC information transfer takes place. During this information 
transfer a parameter cl_data is exchanged between the corresponding CLs which is transparent to the RLC. The cl_data 
contains specific information needed for the coordination of the CLs. 

7.3 Link adaptation in Direct Link phase 

No new HE PDUs are defined for link adaptation in DiL. 

7.4 Power Control in Direct Link phase 

RLC_DM_POWER_CONTROL 

The transfer syntax table of RLC_DM_POWER_CONTROL message is shown below. 

Table 34: Transfer Syntax of RLC_DM_POWER_CONTROL 





8 


7 1 6 


5 


4 


3 1 2 


1 


Octet 3 




dm -due-type 


adjust-tx 


Octet 4 


wt-tx-level 


future use 


Octet 5 






not used 






Octet 6 


Octet 7 


not L 


jsed 



Semantics: 



Parameter 


O/M 


Description 


dm-duc-type 


M 


Indicates whether DiL PC message concerns: 

0: unicast traffic from peer WT 

1 : multicast/broadcast traffic from peer WT 


adjust-tx 


M 


Recommended adjustment of transmit power level at peer WT 


wt-tx-level 


M 


Actual transmit power level of Sender 



dm-duc-type field indicates whether the RLC_DM_POWER_CONTROL message concerns unicast or 
multicast/broadcast traffic from the peer WT. 

During connectivity check, the field adjust_tx in RLC_DM_POWER_CONTROL message is set to 0000, which 
indicates that the WT was not able to make a recommendation for the transmit power level, since it has not been able to 
perform any measurements of reception quality. 
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Table 35 shows the mapping of the field adjust-tx, using 4 bits and a step size of 3dB. 

Table 35: Mapping of adjust-tx field 



adjust-tx 


Adjust power level by: 


0000 


No change/ 
Not enough measurements 


0001 


-3dB 


0010 


-6dB 






0111 


-21 dB 


1000 


Not used 


1001 


+3dB 


1010 


+6dB 






1111 


+21 dB 



Table 36 shows the mapping of wt-tx-level, using 4 bits and a step size of 3dB. This is the same mapping and accuracy 
as for the CC transmission power AP_Tx_Level [3]. 

Table 36: Mapping of wt-tx-level field 



wt-tx-level 


Mean EIRP [dBm] 


Accuracy [dB] 


1111 


30 


+/-4 


1110 


27 


+/-4 


1101 


24 


+/-4 


1100 


21 


+/-4 


1011 


18 


+/-4 


1010 


15 


+1-5 


1001 


12 


+1-5 


1000 


9 


+1-5 


0111 


6 


+/-6 


0110 


3 


+/-6 


0101 





+/-6 


0100 


-3 


+/-6 


0011 


-6 


+/-6 


0010 


-9 


+/-6 


0001 


-12 


+/-8 


0000 


-15 


+/-8 



7.5 Link quality calibration for DIVI operation 

RLC_CALIBRATION_MEASUREMENT_TRIGGER 

The transfer syntax table of RLC_CALIBRATION_MEASUREMENT_TRIGGER message is shown below. 

Table 37: Transfer Syntax of RLC_CALIBRATION_MEASUREMENT_TRIGGER 





8 7 6 


5 4 


3 2 1 


Octet 3 




trigger-type 


future use 


Octet 4 


mac-id-1 (presence depending on trigger-type) 


Octet 5 


mac-id-2 (presence depending on trigger-type) 


Octet 6 


mac-id-3 (presence depending on trigger-type) 


Octet 7 


not used 
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Semantics: 



Parameter 


0/M 


Description 


trigger-type 


M 


2 bits that indicate if one, two, three or all WTs are triggered: 

00 -^ All WTs are triggered (no MAC-ID included) 

01 -^ One WT is triggered 

1 -^ Two WTs are triggered 

1 1 -^ Three WTs are triggered 


mac-ids 


M 


MAC-ID of triggered WTs (up to 3), in case of selective calibrations. 



RLC_CALIBRATION _ MEASUREMENT 

The transfer syntax table of RLC_CALIBRATION_MEASUREMENT message is shown below (no parameters are 
contained). 

Table 38: Transfer syntax of RLC_CALIBRATION_MEASUREMENT 





8 1 7 1 6 


5 1 4 1 3 1 2 1 1 


Octet 3 






Octet 4 






Octet 5 


Not used 


Octet 6 


Octet 7 







Semantics: 



Parameter 


O/IM 


Description 






No parameters included 



RLC_CALIBRATION _REPORT_TRIGGER 

The transfer syntax table of RLC_CALIBRATION_REPORT_TRIGGER message is shown below. 

Table 39: Transfer syntax of RLC_CALIBRATION_REPORT_TRIGGER 





8 7 6 


5 4 


3 2 1 


Octet 3 




trigger-type 


future use 


Octet 4 


mac-id-1 (presence depending on trigger-type) 


Octet 5 


mac-id-2 (presence depending on trigger-type) 


Octet 6 


mac-id-3 (presence depending on trigger-type) 


Octet 7 


not used 



Semantics: 



Parameter 


0/IVI 


Description 


trigger-type 


M 


2 bits that indicate if one, two, three or all WTs are triggered to report: 

00 -^ Report from all WTs 

01 ^ Report from one WT 

10 -^ Report from two WTs 

1 1 ^ Report from three WTs 


mac-ids 


M 


MAC-IDs of up to 3 WTs (8 bits each), in case of selective reports 
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RLC SHORT CALIBRATION REPORT 



The transfer syntax table of RLC_CALIBRATION_REPORT message in SCH: 

Table 40: Transfer syntax of RLC_SHORT_CALIBRATION_REPORT 





8 1 7 1 6 


5 


4 


1 3 1 2 1 1 


Octet 3 




rep-buf-status 


future use 


Octet 4 


mac-id-1 


Octet 5 


rss2-of-wt-1 


future use 

Future use 


Octet 6 


mac-id-2 


Octet 7 


rss2-of-wt-2 


future use 



RLC CALIBRATION REPORT 

The transfer syntax table of RLC_CALIBRATION_REPORT message in LCH: 

Table 41 : Transfer syntax of RLC_CALIBRATION_REPORT 





8 1 7 1 6 1 5 1 4 


3 


2 1 1 


Octet 4 


number-of-reports 


rep-buf- 
status 


future use 


Octet 5 


mac-id-1 


Octet 6 


rss2-of-wt-1 




future use 


Octet 7 


mac-id-2 


Octet 8 


rss2-of-wt-2 




future use 


Octet 9 


mac-id-3 


Octet 10 


rss2-of-wt-3 




future use 


Octet 11 


mac-id-4 


Octet 12 


rss2-of-wt-4 




future use 


Octet... 


etc for other wts 


Octet ... 


not used 


Octet ... 


Octet 51 



Semantics: 



Parameter 


0/M 


Description 


rep-buf-status 


M 


Indicates whether reports still need to be broadcast. 
0: All reports have been transmitted 
1 : Still reports in buffer 


cap-report-list 


M 


Each report contains a MAC-ID (8 bits) and the corresponding RSS2 value 
(6 bits) of the WT. 



RLC_CALIBRATION_LINKQUALITYMAP_REQUEST 

The transfer syntax table of RLC_CALIBRATION_LINKQUALITYMAP_REQUEST message: 

Table 42: Transfer syntax of RLC_CALIBRATION_LINKQUALITYMAP_REQUEST 





8 


7 


6 


5 


4 


3 1 2 


1 


Octet 3 




request- 
type 


future use 


Octet 4 


mac-id 


Octet 5 


not used 


Octet 6 


Octet 7 
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Semantics: 



Parameter 


0/M 


Description 


request-type 


M 


Indicates whether the whole map is requested or only information related to 

one WT with mac-id 

0: Whole IVIap request 

1 : Only RSS2 information related to the MAC-ID given below 


mac-id 


M 


mac-id of the specific WT in case of request-type=1 . With request-type=0 
the field is not present 



RLC_CALIBRATION_LINKQUALITYMAP 

The transfer syntax table of RLC_CALIBRATION_LINKQUALITYMAP message. 

Table 43: Transfer syntax of RLC_CALIBRATION_LINKQUALITYMAP 





8 1 7 1 6 1 5 


4 


3 1 2 1 1 


Octet 4 


number-of-mac-ids 


map-ext-ind 


future use 


Octet 5 


mac-id-of-sender-wt-i 


Octet 6 


no-of-reports-wt-i 


Octet 7 


mac-id-receiver-wt-ix 


Octet 8 


age-of-rss2 rss2-for-wt-ix 


Octet 9 


mac-id-receiver-wt-iy 




age-of-rss2 rss2-for-wt-iy 


Octet 6+(2*N) 




Octet 7+(2*N) 


mac-id-of-sender-wt-j 


Octet 8+(2*N) 


no-of-reports-wt-j 


Octet 9+(2*N) 


mac-id-wt-jx 


Octet 10+(2*N) 


age-of-rss2 rss2-for-wt-jx 


Octet 11 +(2*N) 


mac-id-wt-jy 


Octet 12+(2*N) 


age-of-rss2 rss2 -for-wt-jy 






8+(2*N)+(2*K) 




9+(2*N)+(2*K) 


... 


Octet 51 









Semantics: 



Parameter 


O/IM 


Description 


number-of-mac-ids 


M 


Number of the MAC-IDs of the WT_xi, whose transmitted RSS2 values are 
being reported by WT i 


map-ext-ind 


M 


extension indication bit whether more 

RLC CALIBRATION LINKOUALITYMAP PDUs follow 


complete-report-list 


M 


Contains following Reports from each WTJ, whose RSS2 values have 

been measured by other WT ix: 

MAC- ID of WTJ (8 Bits) 

Number of reports for measurement PDU from WTJ (8 Bits) 

Report list (N X 16 Bits): 

MAC- ID of WTJx (8 Bits) 

RSS2 measured by WTJx when signal transmitted by WTJ (6 Bits) 

Age (2 bits) indicates the time since the measurement was performed: 

00: within last 100 ms 

01: within last 250 ms 

10: within last 500 ms 

11:olderthan 1 s 

In case of a partial quality map only the reports concerning one reporting 

WT i are included in the PDU 



If RLC_CALIBRATION_LINKQUALITYMAP contains a partial map, dedicated to one WTJ only, it is transmitted 
on DL DCCH, if it contains a complete quality map or a part of the complete quality map it is transmitted on DL 
RBCH. 
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NOTE: The complete quality map may not fit into one LCH, in which case several 

RLC_CALIBRATION_LINKQUALITYMAP PDUs will be broadcast by the CC. number-of-mac-ids 
only indicates the number of WT_i in the current PDU, whose RSS2 values have been measured by other 
WT ix. 



7.6 



DLC User Connection Control 



7.6.1 



Fixed Slot Allocation for DM 



An FSA connection set-up, release, modify, etc. is identified by the allocation-type field in the duc-direction-descr 
being set to the value "fsa" (see TS 101 761-2 [2]). The FSA specific parameters of the connection are contained in the 
fsa-descr, which is also part of the duc-direction-descr. The fsa-descr is only present inside the duc-direction-descr 
when allocation-type is set to "fsa". 

The fsa-descr is defined in TS 101 761-2 [2]. It contains the parameters: phy-mode-lch, nb-of-lch, min-nb-of-lch, 
start-pointer and start-mac-frame. In case of an FSA-RR only the parameters phy-mode-lch, nb-of-lch, min-nb-of-lch 
and start-mac-frame are used. For an FSA-RR the start-pointer shall be filled with bits. In case of an FSA-RG only 
the parameteTS phy-mode-lch, nb-of-lch, start-pointer and start-mac-frame are used. For an FSA-RG min-nb-of-lch shall 
be set to the value of nb-of-lch. The meaning and use of the parameters in case of FSA-RR and FSA-RG is summarized 
in Table 44. 

Table 44: Parameters of the fsa-descr in case of FSA-RR and FSA-RG 



Parameter 


0/M 


Description 


phy-mode-lch 


M 


Phy-mode of the LCHs (4 bits) 


nb-of-lch 


M 


Number of requested (in case of FSA-RR) or granted (in case of FSA-RG) LCHs 
(8 bits) 


min-nb-of-lch 


M 


IVIinimum number of requested LCHs in case of an FSA-RR. In case of an FSA-RG the 
min-nb-of-lch shall be set to the same value as the granted nb-of-lch (8 bits) 


start-pointer 


M 


Pointer to the position of the Fixed Slot Allocation in the IVIAC Frame (used in case of 
an FSA-RG). Same meaning and coding as for Resource Grants 
Shall be set to in case of an FSA-RR (13 bits) 


start-mac-frame 


M 


In case of an FSA-RG, start-mac-frame gives the exact IVIAC Frame to start FSA. In 
case of an FSA-RR start-mac-frame may contain an indicative value, when the WT 
wants its connection to be started (16 bits) 



The transfer syntax tables of the concerned RLC PDUs are contained in TS 101 761-2 [2]. 
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7.6.2 Multicast in DiL pinase 



The transfer syntax tables below display the structures of all messages used for Direct Link Multicast Connection Setup, 
Modify and Release. 



7.6.2.1 



RLC-DM-MC-SETUP encoding 





8| 7 |6|5|4|3|2|1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


CL-ID 


Octet 7 


EXT- 
IND 


CL-ATTRIBUTE-LENGTH(L) 


#of DUC:s 


Octet 8 


#of DUC:s(N) 


Future use 


Octet 9 


DUC1 -DIRECTION 


DLCC-ID 


Octet 10 


MIN-REQ-RECEIVERS 




CL-CONN ATTR 


Octet Y 


DUC1-FW-TYPE-0F- 
ALLOCATION 


Future 
use 


cyclic- 
prefix 


FEC- 
USED 


EC-MODE 


Octet... 


DUC1-FW-NUM-0F- 


Future 


DUC1-FW-AR0-WIN-SIZE 1 




FEC-FW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


REO 
SCH 


PHY-MODE-SCH 


PHY-MODE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINIMUM-NUM-OF-LCH 


Octet ... 


Future use 1 PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-Dointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter 


frame-count 1 


Octet X 


DUC1-BW-TYPE-0F- 
ALLOCATION 


Future 
use 


Cyclic- 
prefix 


FEC- 
USED 


EC-MODE 


Octet... 


DUC1-BW-NUM-0F- 


Future 


DUC1-BW-AR0-WIN-SIZE | 




FEC-BW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


REO 
SCH 


PHY-MODE-SCH 


PHY-MODE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINIMUM-NUM-OF-LCH 


Octet ... 


Future use PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-Dointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet ... 


CL-COMMON-ATTR-LENGTH 


Octet ... 


CL-COMMON-ATTR 


Octet ... 


Octet ... 


Octet ... 


Not used 


Octet ... 


Octet 51 

















Y= IOh-L 

X= 10H-LH-6if asymmetric duplex with FCA and ARQ or FEC. 



£75/ 



81 



ETSI TS 101 761-4 VI .3.2 (2002-01) 



Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


0/M 


Description 


source-mac-id 


M 


identifies tlie multicast sender 


min-req-receivers 


M 


number of receivers required to establish the multicast connection 


cl-common-attr 


M 


common attributes concerning CL 


cl-common-attr-length 


M 


giving the length of the cl-common-attr field, can be set to zero 



7.6.2.2 



RLC-DM-MC-CONNECT encoding 





8 1 7 |6| 5 1 4 1 3 1 2 1 1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


CL-ID 


Octet 7 


Future use CL-ATTRIBUTE-LENGTH(L) | # of DUC:s 


Octet 8 


#of DUC;s(N) 


Future use 


Octet 9 


DUC1- DIRECTION 


DLCC-ID 




CL-CONN ATTR 




Octet Y 


DUC1-FW-TYPE-0F-ALL0CATI0N Future use 


Cyclic-prefix 


FEC-USED 1 EC-MODE 


Octet... 


DUC1 -FW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1-FW-AR0-WIN-SIZE 




FEC-FW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


REG SCH 1 PHY-MODE-SCH 


PHY-MGDE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter 


frame-count 


Octet X 


DUC1-BW-TYPE-0F-ALL0CATI0N| Future use 


cyclic-prefix 


FEC-USED 1 EC-MODE 


Octet... 


DUC1 -BW-NUM-OF-RETRANSMISSIONS 


Future use 


DUC1 -BW-ARG-WIN-SIZE 




FEC-BW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


REG SCH 1 PHY-MGDE-SCH 


PHY-MGDE-LCH 


Octet... 


REGUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MGDE-LCH 


Octet ... 


NB-GF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet... 


Not used 


Octet... 


Octet 51 











Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


O/IM 


Description 


source-mac-id 


M 


identifies the multicast sender 
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7.6.2.3 



RLC-DM-MC-CONNECT-ACK encoding 





8 1 7 


6 1 5 1 4 1 3 


2 1 1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


CL-ID 


Octet 7 


Future 
use 


CL-CONN-ATTR-LENGTH (L) 


# Of DLCC:s-i-CL- 
ATTR 


Octet 8 


# of DLCCs (N) 


Future use 


Octet 9 


Future use 


DLCC-ID-1 


Octet ... 


CL-CONN-ATTR-1 


Octet ... 


Future use 


DLCC-ID-N 




Octet ... 


CL-CONN-ATTR -N 


Octet 8+L*N 


Octet ... 


Not used 


Octet ... 


Octet 51 



Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


O/M 


Description 


source-mac-id 


M 


identifies the multicast sender 



7.6.2.4 



RLC-DM-MC-CONNECT-COMPLETE encoding 





8 1 7 


6 1 5 1 4 1 3 1 2 1 


1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


Future use | # of DLCC:s (N) 


Octet 7 


Future use 


DLCC-ID -1 


Octet ... 


Future use 




Octet 5+N 


Future use 


DLCC-ID-N 


Octet 6+N 


Not used 


Octet ... 


Octet 51 



Semantics of parameters specifically used for the DiL multicast case: 



Parameter 


O/IVI 


Description 


source-mac-id 


M 


identifies the multicast sender 



7.6.2.5 



RLC-DM-MC-CONNECT-COMPLETE-ACK encoding 





8 1 7 1 6 


5 1 4 1 3 1 2 


1 1 


Octet 3 




Future use 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


Future use 


Octet 7 



Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


O/IM 


Description 


source-mac-id 


M 


identifies the multicast sender 
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7.6.2.6 



RLC-DM-MC-MODIFY-REQ encoding 





8|7|6|5|4|3|2|1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


Future 
use 


CL-ATTRIBUTE-LENGTH(L) 


#ofDUC:s 


Octet 7 


#ofDUC:s(N) 


Future use 


Octet 8 


DUC1-DIRECTI0N 


DLCC-ID 




CL-CONN ATTR 




Octet Y 


DUC1-FW-TYPE-0F- 
ALLOCATION 


Future 
use 


cyclic- 
prefix 


FEC- 
USED 


EC-MQDE 


Octet... 


DUC1-FW-NUM-0F- 
RETRANSMISSIONS 


Future 
use 


DUC1 -FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


REQ 
SCH 


PHY-MODE-SCH 


PHY-MQDE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter 


frame-count 


Octet X 


DUC1-BW-TYPE-0F- 
ALLOCATION 


Future 
use 


cyclic- 
prefix 


FEC- 
USED 


EC-MODE 


Octet... 


DUC1-BW-NUM-0F- 
RETRANSMISSIONS 


Future 
use 


DUC1 -BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


REQ 
SCH 


PHY-MODE-SCH 


PHY-MQDE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MQDE-LCH 


Octet ... 


NB-QF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet... 


Not used 


Octet... 


Octet 51 

















Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


0/M 


Description 


source-mac-id 


M 


identifies the multicast sender 
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7.6.2.7 



RLC-DM-MC-MODIFY encoding 





8|7|6|5|4|3|2|1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


Future 
use 


CL-ATTRIBUTE-LENGTH(L) 


#of DUC:s 


Octet 7 


#of DUC:s(N) 


Future use 


Octet 8 


DUC1-DIRECTI0N 


DLCC-ID 


Octet 9 


repetition-counter 


Octet 10 


repetition-counter frame-count 




CL-CONN ATTR 




Octet Y 


DUC1-FW-TYPE-0F- 
ALLOCATION 


Future 
use 


cyclic- 
prefix 


FEC- 
USED 


EC-MQDE 


Octet... 


DUC1-FW-NUM-0F- 
RETRANSMISSIONS 


Future 
use 


DUC1 -FW-ARQ-WIN-SIZE 




FEC-FW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


REQ 
SCH 


PHY-MODE-SCH 


PHY-MQDE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use PHY-MODE-LCH 


Octet ... 


NB-OF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter 


frame-count 


Octet X 


DUC1-BW-TYPE-0F- 
ALLOCATION 


Future 
use 


cyclic- 
prefix 


FEC- 
USED 


EC-MQDE 


Octet... 


DUC1-BW-NUM-0F- 
RETRANSMISSIONS 


Future 
use 


DUC1 -BW-ARQ-WIN-SIZE 




FEC-BW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


REQ 
SCH 


PHY-MODE-SCH 


PHY-MQDE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet ... 


Future use | PHY-MQDE-LCH 


Octet ... 


NB-QF-LCH 


Octet ... 


MIN-NB-OF-LCH 


Octet ... 


start-pointer 


Octet ... 


start-pointer Future use 


Octet ... 


repetition-counter 


Octet ... 


repetition-counter frame-count 


Octet... 


Not used 


Octet... 


Octet 51 

















Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


0/M 


Description 


source-mac-id 


M 


Identifies the multicast sender 


repetition-counter 


M 


repetition of the value frame-count in BCCH 


frame-count 


M 


The MAC frame number appearing in BCCH 
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7.6.2.8 



RLC-DM-MC-MODIFY-ACK encoding 





8 


7 6 5 4 3 2 1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


CL-CONN-ATTR-LENGTH | # of DLCC:s-^CL-CONN-ATTR 


Octet 7 


#of 
DLCCs 


Future use 


Octet 8 


Future use | DLCC-ID-1 


Octet ... 


CL-CONN-ATTR-1 




Future use | DLCC-ID ... 




CL-CONN-ATTR... 




Not used 


... 


Octet 51 







Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


0/M 


Description 


source-mac-id 


M 


Identifies the multicast sender 



7.6.2.9 



RLC-DM-MC-RELEASE encoding 





8 1 7 1 6 


1 5 1 4 1 3 1 2 


1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCE-MAC-ID 


Octet 6 


CAUSE 


1 # of DLCC:s 




Octet 7 


Future use 


DLCC-ID -1 


Octet 8 


Future use 




Octet ... 


Future use 


DLCC-ID N 


Octet ... 


Not used 


Octet... 


Octet 51 



Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


O/IM 


Description 


source-mac-id 


M 


identifies tlie multicast sender 



7.6.2.1 RLC-DIVI-IVIC-RELEASE-ACK encoding 





8 1 7 1 6 


1 5 1 4 1 3 1 2 


1 


Octet 4 


PEER-MAC-ID 


Octet 5 


SOURCEMAC-ID 


Octet 6 


Future use 


1 # of DLCCis 




Octet 7 


Future use 


DLCC-ID-1 


Octet 8 


Future use 




Octet ... 


Future use 


DLCC-ID-N 


Octet ... 


Not used 


Octet... 


Octet 51 



Semantics of parameters specifically introduced for the DiL multicast case: 



Parameter 


0/IVI 


Description 


source-mac-id 


M 


identifies tlie multicast sender 
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7.7 



Dynamic CC Selection 



In each CC Probing Frame a CC-capable device in the CC Selection Process transmits a Probing Beacon with the 
structure of the usual BCCH and the following content: 

Table 45: Contents of the CC Probing BCCH 



Name 


Length (bits) 


Setting 


Frame counter (scrambler seed) 


4 


as defined in basic DLC TS 


NET-ID 


10 


0000000000 


AP-ID 


10 


0000000000 


Antenna ID 


3 


000 


AP TX level 


4 


1111 


AP RX UL level 


3 


000 


Pointer to FCH 


12 


000000000000 


Length FCH 


4 


0000 


PHY Mode of FCH 


2 


00 


Pointer to RCH 


13 


0000000000000 


Length of RCH 


5 


00000 


Guard space between RCH 


2 


00 


DL RBCH indicator 


1 





DST (Data to sleeping terminals) 


1 





Uplink preamble 


1 





Version indicator 


3 


000 


AP traffic load indicator 


3 


000 


IVIaximum power indicator 


1 


1 


# of antenna elements 


3 


000 


Future use 


14 


any 


CRC 


24 


as defined in TS 101 761-1 [1] 


Total length 


120 





The CC Probing BCCH is identified uniquely by "Length of RCH" = 00000, which is not allowed in normal operation. 
All other fields shall be ignored on reception of a CC Probing BCCH. 
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7.8 CC Responsibility Handover 

7.8.1 Encoding of CC Database Parameters for CC Handover 

The H/2-HD specific parameters shall be encoded as in Table 46. 

Table 46: Transfer Syntax Table of H/2-HD Specific Parameters 
(Content-field of an H/2-HD-DATA-BLOCK) 





8|7|6|5|4|3|2|1 


Octet 1 


mac-id 


Octet 2 


dic-version-selected 


Octet 3 


ric-version-selected 


Octet 4 


64- 

qam 

? 


freq-band 


dm-cap 


support- 
tea 


support- 
fsa 


nr-cl-vid (N) 


Octet 5 


cl-id-1 


Octet 6 


cl-version-1 


... 


Other CL-ID and CL- Version 


Octet 5+(2*N) 


ho- 
cap 


cc-ho-cap 


duty-cycle 


time-gap-ach-ul 


Octet 6+(2*N) 


arq-delay-rx 


arq-delay-tx 


auth-selected 


Octet 7+(2*N) 


encr-selected 


cyclic 
prefix 


Future use 


Octet 8+(2*N) 


dil-power- 
control 


rx-arq-win-size 


tx-arq-win-size 


Octet 9+(2*N) 


length-of-measurement-DFS Future use 


Octet 10+(2*N) 


sleep-interval 


Octet 11+(2*N) 


cl-common-attr-length (M octets) Future use 


... 


cl-common-attr 


Octet 
11+(2*N)+M 


Oct.12+(2*N)+M 


nr-mc-groups (L) Future use 


... 


mac-id-1 


Octet 
12+(2*N)+M+L 


other-mac-ids 


13+(2*N)+M+L 


auth- 
id- 
pr? 


mt-auth-id-type 


Future use 


... 


mt-auth-id 


Octet 

19+(2*N)+M+L 

or21+(2*N)+M+L 

or 59+(2*N)+M+L 

or 
105+(2*N)+M+L 


Octet 1 


mac-id 


Octet 2 


dic-version 


Octet 3 


ric-version 


Octet 4 


Future use nr-cl-vid (N) 


Octet 5 


cl-id-1 


Octet 6 


cl-version-1 


... 


Other CL-ID and GL-Version 


Octet 5+(2*N) 


64- 

qam 
? 


dm-cap 


dm-use- 
key 


polling? 


fsa? 


time-gap-ach-ul 


Octet 6+(2*N) 


arq-delay-rx 


arq-delay-tx 


auth-selected 


Octet 7+(2*N) 


encr-selected 


Future use 


Octet 8+(2*N) 


dil-power- 
control 


rx-arq-win-size 


tx-arq-win-size 


Octet 9+(2*N) 


length-of-measurement-DFS Future use 


Octet 10+(2*N) 


sleep-interval 


Octet 11 +(2*N) 


cl-common-attr-length (M octets) Future use 
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8 


7 


6 1 5 1 4 1 


3 1 2 1 


1 


... 


cl-common-attr 


Octet 
11+(2*N)+M 


Oct.12+(2*N)+M 






nr-mc-groups (L) 


Future use 




... 


mac-id-1 


Octet 
12+(2*N)+M+L 


other-mac-ids 


13+(2*N)+M+L 


mt- 
id- 
pr? 


auth-id- 
pr? 


mt-auth-id-type 


Future use 


... 


mt-id 


Octet 
45+(2*N)+M 


... 


mt-auth-id 


Octet 

51+(2*N)+M 

or 53+(2*N)+M 

or 92+(2*N)+M 



The optional parameter mt-auth-id is transmitted at the end of the H/2-HD specific field. A flag auth-id-pr indicates 
whether MT-AUTH-ID is present or not. 

The total length of the H/2-HD specific field depends on the number N of CLs present within the H/2-HD (nr-cl-vid), 
the length M of the cl-common-attr field, the number of multicast groups L the H/2-HD is participating in 
(nr-mc-groups) as well as the presence and the type of the MT-AUTH-ID (auth-id-pr and mt-auth-id-type). The H/2- 
HD specific field may not fit into one PDU (always a maximum of 48 octets available). 

For this reason the transmission as byte string has been foreseen for the parameter transfer (see clause 6.8.2). The 
transmitted byte string consists of data blocks. Two types of data blocks are distinguished: H/2-HD-DATA-BLOCK 
and CONN-DATA-BLOCK. A data block consists of a type-field, a length-field and a content-field. An 
H/2-HD-DATA-BLOCK contains the information relevant to one H/2-HD. The content-field follows the structure in 
Table 46 in case of an H/2-HD-DATA-BLOCK. The length-field is to indicate the variable length of the content-field, 
which varies from 13 octets to 170 octets in case of an H/2-HD-DATA-BLOCK. The length-field is to indicate the 
variable length of the content-field in number of octets. The length-field has itself a length of 8 bits. The type-field is 
also 8 bits long. Only the last bit is to distinguish between the two types of data blocks (0 for H/2-HD-DATA-BLOCK, 
1 for CONN-DATA-BLOCK), the other bits are for future use. Table 47 illustrates the structure of a data block. 

Table 47: General Structure of a Data Block 





8 


7 


6 


5 1 4 


3 


2 


1 


Octet 1 


type-field 


Octet 2 


length-field 


Octet 3 


content-field 


... 



The content-field of a CONN-DATA-BLOCK, which contains the parameters of one unicast or multicast DM 
connection, shall be encoded like shown in Table 48. 
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Table 48: Transfer Syntax Table of DIL Connection Specific Parameters 
(Content-field of a CONN-DATA-BLOCK) 





8|7|6|5|4|3|2|1 


Octet 1 


first-mac-id 


Octet 2 


second-mac-id 


Octet 3 


cl-id 


Octet 4 


dicc-id 


direction 
DIRECTION 


Octet 5 


cl-conn-attr-length Future use 


Octet 5+M 


cl-conn-attr 


Octet Y 


DUC-FW-TYPE-OF- 
ALLOCATION 


Future 
use 


cyclic- 
prefix 


FEC- 
USED 


ec-mode 


Octet... 


DUC-FW-NUM-OF-RETRANSMISSIONS 


Future 
use 


DUC-FW-ARO-WIN-SIZE 




FEC-FW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


REQ 
SCH 


PHY-MODE-SCH 


PHY-MODE-LCH 


Octet... 


REQUESTED-NUIVI-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 


Octet X 


DUC-BW-TYPE-OF- 
ALLOCATION 


Future 
use 


cyclic- 
prefix 


FEC- 
USED 


ec-mode 


Octet... 


DUC-BW-NUM-OF-RETRANSMISSIONS 


Future 
use 


DUC-BW-ARO-WIN-SIZE 




FEC-BW 


Future Use 


Octet... 


PER-#-MAC-FRAME(SCH) 


PER-#-MAC-FRAME(LCH) 


Octet... 


REQ 
SCH 


PHY-MODE-SCH 


PHY-MODE-LCH 


Octet... 


REQUESTED-NUM-OF-LCH 


Octet... 


MINUMUM-NUM-OF-LCH 



The total length of the DiL connection specific field depends on many parameters like the length of the cl-common-attr 
field, the presence of the forward-descriptor respectively backward-descriptor, the fee-used bit (green octet may not 
be present) and the ec-mode (blue octets may not be present). The maximum length of the content-field can be 
50 octets. The CONN-DATA-BLOCK follows the general structure of a data block in Table 47. 

H/2-HD-DATA-BLOCKS and CONN-DATA-BLOCKS are concatenated to form the byte string that is transmitted as 
payload of the RLC_TRANS_CC_DATA PDUs. First the H/2-HD-DATA-BLOCKS of all HDs shall be transmitted 
followed by the CONN-DATA-BLOCKS of all DM connections. 

NOTE: A data block is segmented if its length exceeds the length of the payload field of an RLC LCH PDU 

(48 octets). By concatenating all received payload fields within (the memory of) the receiver, automatic 
reassembling can be performed. 

7.8.2 Transfer syntax tables of CC handover PDUs 

As shown in Table 49 no parameters are included in the RLC_CC_HO_REQUEST, RLC_CC_HO_REQUEST_ACK, 
RLC_CC_HO_NOTIFY, RLC_START_CC_ACK and RLC_CC_START_OPERATION. 

Table 49: RLC_CC_HO_REQUEST, RLC_CC_HO_REQUEST_ACK, RLC_CC_HO_NOTIFY, 
RLC_START_CC_ACK and RLC_CC_START_OPERATION encoding 





8 1 7 1 6 


5 1 4 1 3 1 2 1 1 


Octet 3 






Octet 4 






Octet 5 


Not used 


Octet 6 


Octet 7 







£75/ 



90 



ETSI TS 101 761-4 VI .3.2 (2002-01) 



The RLC_TRANS_CC_DATA PDU is encoded like illustrated in Table 50. In the transfer syntax table the whole PDU 
is shown including parts defined in TS 101 761-1 [1] and TS 101 761-2 [2]. The reason is that the Sequence Number 
field defined in TS 101 761-1 [1] is used for the Go-Back-n ARQ mechanism (see clause 6.8.3). During one CC 
Handover, the Sequence Number is incremented by 1 (modulo 1024) with each transmitted RLC_TRANS_CC_DATA 
PDU (and starting with 0). The purpose of the EXT-IND field is to indicate if the PDU is the last 
RLC_TRANS_CC_DATA PDU transmitted in this CC Handover. For all previous PDUs the field is set to 0. The byte 
string contains the H/2-HD-DATA-BLOCKs and CONN-DATA-BLOCKs the purpose and encoding of which has been 
explained in clause 7.7.1. 

Table 50: RLC_TRANS_CC_DATA encoding 





8 1 7 


6 1 5 1 4 1 3 1 2 1 1 


Octet 1 


Ich-pdu-type 


sequence-number 


Octet 2 


sequence-number Future use 


Octet 3 


ric-pdu-type 


Octet 4 


ext-ind Future use 


Octet 5 


Byte-String (containing H/2-HD-DATA-BLOCKs and CONN-DATA-BLOCKs) 


Octet 6 


Octet... 


Octet... 


Octet... 


Octet ... 


Octet ... 


Octet 51 


Octet 52 


CRC-24 


Octet 53 


Octet 54 







A certain number of RLC_TRANS_CC_DATA PDUs is acknowledged by one RLC_TRANS_CC_DATA_ACK PDU 
by the receiver. The receiver shall send at least one RLC_TRANS_CC_DATA_ACK PDU per frame (if there are 
RLC_TRANS_CC_DATA PDUs that have not yet been acknowledged). The RLC_TRANS_CC_DATA_ACK PDU 
contains the Sequence number of the RLC_TRANS_CC_DATA PDU that is expected next (see Table 51). The error 
bit indicates whether the sender (CC) shall re-send RLC_TRANS_CC_DATA PDUs from the contained Sequence 
number on. In case the error bit has the value 0, the sender shall take no action. 

Table 51 : RLC_TRANS_CC_DATA_ACK encoding 





8 


7 


1 6 


5 1 4 


1 3 1 2 1 1 


Octet 3 


^^^r 


sequence-number 
BROADCAST ? 


Octet 4 






sequence-number 


rr-flag Future use 


Octet 5 


not used 


Octet 6 


Octet 7 



The RLC_START_CC PDU contains the start-mac-frame parameter, which determines the start time for the new CC to 
take over CC responsibility (Table 52). 

Table 52: RLC_START_CC encoding 





8 1 7 1 6 


5 1 4 1 3 1 2 


1 


Octet 3 




Future use 


Octet 4 


Repetition-counter 


Octet 5 


Repetition-counter 


Frame-count 




Octet 6 


Not used 


Octet 7 
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7.9 Authentication key management 

The transfer syntax table of the RLC_AUTHENTICATION_KEY_REQUEST is defined in Table 53. 
Table 53: RLC_AUTHENTICATION_KEY_REQUEST encoding 





8 1 7 1 6 1 5 1 4 1 3 


2 1 1 


Octet 4 


mt-id-number-length 


Future use 


Octet 5 


mt-id-number 


Octet 6 


Octet... 


Octet... 


Octet... 


Octet ... 


Not used 


Octet ... 


Octet 51 



Semantics: 



Parameter 


0/M 


Description 


MT-ID-NUMBER- 
LENGTH 


M 


6 bits to indicate tlie length of the MT-ID-NUMBER in number of octets. 


MT-ID-NUMBER 


M 


Some Identifier of the WT, where MT-ID-NUMBER is from 1 to 47 octets. 



No parameters are included in the RLC_AUTHENTICATION_KEY_REQUEST_ACK PDU (see Table 54). 
Table 54: RLC_AUTHENTICATION_KEY_REQUEST_ACK encoding 





8|7|65|4|3|2|1 


Octet 3 




Octet 4 


Not used 


Octet 5 


Octet 6 


Octet 7 



Table 55 shows the encoding of the RLC_AUTHENTICATION_KEY_TRANSFER PDU. 

Table 55: RLC_AUTHENTICATION_KEY_TRANSFER encoding 





8 


7 1 6 


5 1 4 1 


3 1 2 


1 


Octet 4 


Valid-key 


Auth-key-length 


Future Use 


Octet 5 




Pin-code-length 




Future use 




Octet 6 


Auth-key 


Octet... 


Octet... 


Pin-code 


Octet... 


Octet ... 


Not used 


Octet ... 


Octet 51 
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Semantics: 



Parameter 


0/M 


Description 


VALID-KEY 


M 


1 bits that equals 1 if the key is valid 


AUTH-KEY-LENGTH 


M 


Length of the AUTHENTICATION KEY in number of octets (6 bits). Only values 
up to binary 100100 are allowed 


PIN-CODE-LENGTH 


M 


Length of the PIN code of the subnet in number of octets (4 bits). Only values up 
to binary 1010 are allowed 


AUTH-KEY 


M 


Common AUTHENTICATION-KEY of the subnet. The length of the field can vary 
from octet to 36 octets 


PIN-CODE 


M 


PIN code of the network in binary format. The length of the field can vary from 
octet to 1 octets 



RLC_AUTHENTICATION_KEY_TRANFER_ACK is defined in Table 56. 

Table 56: RLC_AUTHENTICATION_KEY_TRANSFER_ACK encoding 





8 


7|6|5|4|3|2|1 




Valid-key 


Future use 


Octet 4 


md5-of-auth-key 


Octet 5 


Octet 6 


Octet... 


Octet 19 


Octet 20 


Not used 


Octet ... 


Octet ... 


Octet 51 







Semantics: 



Parameter 


0/M 


Description 


VALID-KEY 


M 


1 bits that equals 1 if the key is valid 


MD5-0F-AUTH-KEY 


M 


Hash value of the AUTH-KEY, generated with the IVID5 algorithm 



8 



Service primitives (informative) 



The following clauses define the service primitives exchanged between the RLC and CL layers within an H/2-HD. The 
additions to the RLC basic specification (TS 101 761-2 [2]) which are needed to meet the home environment 
requirements are documented. 



8.1 Primitive types 



Four primitive types may be used: 

• req (request), for a higher layer to request service from a lower layer; 

• cnf (confirm), for the layer providing the service to confirm that the activity has been completed; 

• ind (indication), for a layer providing a service to notify the next higher layer of any specific service related 
activity; 

• rsp (response), for a layer to acknowledge receipt of an indication primitive from the next lower layer. 
The defined types for each category of primitive are shown as a list in curly brackets. 
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NOTE: These primitives are defined only for the purpose of describing layer-to-layer interactions. The primitives 
are defined as an abstract list of parameters, and their concrete realization may vary between 
implementations. No formal testing of primitives is intended. The following primitive definitions have no 
normative significance. 

8.2 Common DLC C-SAP primitives to Convergence Layer 

This clause summarizes the common primitives between the convergence layer and the RLC layer whose realization is 
required for any supported CL. 



Convergence Layer 



DLC C-SAP 
Primitives 



„R3d^ /A^ociato^ /^T^^V^ 
Resource ) ( Control ) (Connection 
VContrqL/ ^ ^ Vpontrol^ 



RLC Primitives 



RLC protocol 



(U 



Figure 33: Reference Model of protocol primitives 

The common primitives at the DLC C-SAP have a correspondence to a subset of the RLC primitives defined in 

TS 101 761-2 [2] and in the present document. The parameters used in the common primitives at the DLC C-SAP are 

equal to or a subset of the RLC parameters defined there. 

One DLC C-SAP common primitive may correspond to one of possibly several RLC primitives. It is the task of the 
RLC functions to control the relation between DLC C-SAP primitives and the RLC primitives. The RLC functions 
invoke the RLC primitives with appropriate parameters. (E.g. a request from the CL to set up 8 connections may result 
in 2 subsequent connection setup sequences at the RLC level, each setting up 4 connections). 

At the CC the MAC ID is used to distinguish between different RLC instances. Each CC-capable WT therefore has to 
support different RLC instances. A basic WT, however, only needs one RLC. 

Realization of the following common DLC C-SAP primitives with their corresponding RLC primitives is necessary for 
all H/2-HDs. 
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Table 57: DLC and corresponding RLC primitives 



DLC C-SAP primitive 


RLC primitive 


DLC_Setup-{ req, ind }; 


DUC SETUP - { req, ind }; 
DM SETUP - { req, ind }; 


DLC_CONNECT - { req, cnf, ind, rsp }; 


DUC_CONN - { req, cnf, ind, rsp }; 
DM CONN - { req, cnf, ind, rsp }; 


DLC_RELEASE - { req, cnf, ind, rsp }; 


DUC_RELEASE - { req, cnf, ind, rsp }; 
DM RELEASE - { req, cnf, ind, rsp }; 


DLC_MODIFY - { req, cnf, ind, rsp }; 


DUC MODIFY - { req, cnf, ind, rsp }; 
DM MODIFY - { req, cnf, ind, rsp }; 


DLC MULTICAST JOIN - { req, cnf, ind, rsp }; 


ACF GROUP JOIN - { req, cnf, ind, rsp }; 


DLC MULTICAST LEAVE - { req, ind }; 


ACF GROUP LEAVE-{req,cnf, ind, rsp}; 


DLC MULTICAST CONNECT - { req, cnf, ind, rsp }; 


DM Multicast CONN - { req, cnf, ind, rsp }; 


DLC MULTICAST RELEASE - { req, cnf, ind, rsp }; 


DM Multicast RELEASE - { req, cnf, ind, rsp }; 


DLC MULTICAST MODIFY -{ req, cnf, ind, rsp }; 


DM Multicast MODIFY - { req, cnf, ind, rsp }; 


DLC CL BROADCAST JOIN - { req, cnf, ind, rsp }; 


ACF CL BROADCAST JOIN - {req, cnf, ind, rsp); 


DLC INFO TRANSFER - { req, cnf, ind, rsp }; 


ACF INFO - { req, cnf, ind, rsp }; 


CCH start cl ho -{ ind, rsp }; 


CCH start cl ho -{ind, rsp}; 


CCH start cc- {ind, rsp}; 


CCH start cc- {ind, rsp}; 


NOTE: One DLC C-SAP primitive may correspond to one of possibly several RLC primitives. It is the task of the 
RLC functions (ACF and DCC) to control the relation between DLC C-SAP primitives and the RLC 
primitives. The RLC functions invoke the RLC primitives with appropriate parameters. 



8.3 Special DLC-C SAP primitives to 1394 Convergence Layer 

If the 1394 CL is to be supported by the H/2 DLC home extension, the following 1394 CL specific DLC C-SAP 
primitives shall be realized in the concerned H/2-HDs. These two 1394-specific primitives are defined to imply that 
some special H/2 DLC services should be provided to the 1394 CL locally in an H/2-HD. There is no peer-to-peer RLC 
message associated with them. 



1394 CL-specifIc DLC C-SAP primitive 



DLC_MAC_FRAME_START - { ind}; 



DLC_MAC_FRAME_NUMBER { ind}; 



The realization of DLC_MAC_FRAME_START is necessary to enable 1394 Cycle Clock propagation from a WCM 
(Wireless Cycle Master) to all other H/2-HDs, where the WCM can be any H/2-HD in the subnet. 

DLC_MAC_FRAME_START should realize a time reference event, which should be generated as a hardware impulse 
at the end of the 16 |J,s broadcast burst preamble TS 101 475 [3]. The processing delay between the assertion of this 
impulse to the 1394 CL and the end of the broadcast burst preamble should be a constant, which is known to the 
1394 CL. After a calibration of the processing delay, DLC_MAC_FRAME_START is used as a reference event to 
trigger all H/2-HDs supporting 1394 CL to read and store the local 1394 CTR (Cycle Time Register) value at the same 
time. The stored 1394 CTR value will be compared to that of the WCM, which is multicast in a LCH by the WCM to all 
other H/2 based 1394 devices in each MAC frame, in order to correct the deviation to the WCM CTR (TS 101 493-3 
and TS 101 493-4 (see bibUography)). 

NOTE: DLC_MAC_FRAME_START could be directly realized by a HW signal from the PHY layer. 

DLC_MAC_FRAME_NUMBER primitive contains the current MAC frame counter value obtained from the BCCH. It 
should be sent to the IEEE 1394 CL in a way, that the current MAC frame counter value is available in the 
IEEE 1394 CL not later than the end of the FCCH phase. The current MAC frame counter value will be included into 
the CTR adjustment protocol PDU in TS 101 493-3 and TS 101 493-4 (see BibUography). 
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Annex A (normative): 
PDU types 



Table A.I : HE LCH PDU messages 



LCH PDU type 


RLC message name 






(0000 0001) 1 


RLC CALIBRATION REPORT 






2 


RLC DM MC SETUP 






3 


RLC DM MC CONNECT 






4 


RLC DM MC CONNECT ACK 






5 


RLC DM MC CONNECT COMPLETE 






6 


RLC DM MC CONNECT COMPLETE ACK 






7 


RLC DM MC RELEASE 






8 


RLC_ DM_MC_RELEASE_ACK 






9 


RLC DM MC MODIFY 






10 


RLC DM MC MODIFY ACK 






11 


RLC TRANS CC DATA 






12 


RLC AUTHENTICATION KEY REQUEST 






13 


RLC AUTHENTICATION KEY TRANSFER 







Table A.2: HE SCH PDU messages 



SCH PDU type 


RLC message name 






(0000 0001)1 


RLC DM POWER CONTROL 






2 


RLC CALIBRATION MEASUREMENT TRIGGER 






3 


RLC CALIBRATION MEASUREMENT 






4 


RLC CALIBRATION REPORT TRIGGER 






5 


RLC SHORT CALIBRATION REPORT 






6 


RLC CALIBRATION LINKOUALITYMAP REQUEST 






7 


RLC CALIBRATION LINKOUALITYMAP 






8 


RLC_CC_HO_REQUEST 






9 


RLC_CC_HO_REQUEST_ACK 






10 


RLC CC HO NOTIFY 






11 


RLC TRANS CC DATA ACK 






12 


RLC START CC 






13 


RLC START CC ACK 






14 


RLC CC START OPERATION 






15 


RLC AUTHENTICATION KEY REQUEST ACK 






16 


RLC AUTHENTICATION KEY TRANSFER ACK 
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Annex B (normative): 
Parameter types 



Table B.I : Parameter types 



WT-TX-LEVEL::= TX-LEVEL 




ADJUST-TX::= ENUMERATED! 
no-adjust (0), 
m3dbm (1), 
m6dbm (2), 
m9dbm (3), 
m12dbm (4), 
m15dbm (5), 
mlSdbm (6), 
m21dbm (7), 
p3dbm (9), 
p6db (10), 
p9dbm (11), 
p12dbm (12), 
p15dbm (13), 
pISdbm (14), 
p21dbm (15)} 




AGE-OF-RSS::= ENUMERATED { 
lastlOOms (0), 
Iast250ms (1), 
lastSOOms (2), 
lastl 000ms (3)} 




AUTH-KEY::= OCTET STRING(SIZE(0..36)) 




AUTH-KEY-LENGTH::=INTEGER(0..36) 




GAL-REPORT::= SEQUENCE { 
mac-id MAC-ID, 
rss2-value RSS2-VALUE } 




CAL-REPORT-LIST::= SEQUENCE 
(SIZE(0..23)) QF CAL-REPQRT 




COMPLETE-REPQRT::= SEQUENCE { 
mac-id MAC-ID, 
rss-report-list RSS-REPQRT-LIST } 




CQMPLETE-REPORT-LIST::= SEQUENCE 
(SIZE(1..31)) QF CQMPLETE-REPQRT 




DATA::= QCTET STRING (SIZE(0..47)) 




DM-DUC-TYPE::= ENUMERATED { 
unicast (0), 
mutli-broadcast (1)} 




EXT-IND::= ENUMERATED! 
data-end (0), 
data-continue (1)} 








MAC-IDS::= SEQUENCE (SIZE(0..3)) QF 
MAC-ID 




MAP-EXT-IND::= ENUMERATED! 
map-end (0), 
map-continue (1)} 




MT-ID-NUMBER::= QCTET STRING (SIZE(1 ..47)) 




MT-ID-NUMBER-LENGTH::=INTEGER(1..47) 




PIN-CQDE::= QCTET STRING(SIZE(0..10)) 




PIN-CQDE-LENGTH::= INTEGER(0..1 0) 




REP-BUF-STATUS::= ENUMERATED { 
reports-transmitted (0), 
reports-in-buffer (1)} 
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REQUEST-TYPE: 


= ENUMERATED { 




whole-map 


(0), 




mac-id-map 


(1)} 





WT-TX-LEVEL::= TX-LEVEL 




RR-FLAG::= ENUMERATED { 
receive-not-ready (0), 
receive-ready (1)} 




RSS2-VALUE 

::= INTEGER(0..63) 




RSS-REPORT::= SEQUENCE { 
mac-id MAC-ID, 
age-of-rss AGE-OF-RSS, 
rss2-value RSS2-VALUE } 




RSS-REPQRT-LIST::= SEQUENCE (SIZE(1..63)) 
OF RSS-REPORT 




SEQUENCE-NUMBER::=INTEGER{0..1024) 








TRIGGER-TYPE::= ENUMERATED { 
all-wts (0), 
one-wt (1), 
two-wt (2), 
three-wt (3) } 


2 bits that indicate if one, two, three or all WTs are 
triggered: 

00 -^ All WTs are triggered (no MAC-ID included) 

01 -^ One WT is triggered 

1 -^ Two WTs are triggered 

1 1 -^ Three WTs are triggered 


VALID-KEY::= ENUMERATED! 
key-not-valid (0), 
key-valid (1)} 
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Annex C (normative): 
RLC timers 



Management of RLC timers is described in TS 101 761-2 [2]. There are three different timers: 

• T_short; 

• T_medium; 

• T_long. 

The following new timers are defined in the present document: 

Table C.I : H/2-HD timers 



H/2-HD 


Value 


T dm mc setup wt 


T short 


T dm mc connect wt 


T short 


T dm mc modify req wt 


T short 


T dm mc release wt 


T short 


T dm mc power control 


T long 


T dm mc setup cc 


T short 


T dm mc connect cc 


T short 


T dm mc connect cmpt cc 


T short 


T dm mc modify cc 


T short 


T dm mc release cc 


T short 


T cc ho request cc 


T short 


T trans cc data cc 


6 msec 


T start cc cc 


T short 


T_dm_mc_connect_ack_wt 


4max_setup_time frames 


T trigger lifetime 


50 msec 
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Annex D (informative): 

Informative SDL FSIVIs concerning Power Control 

NOTE: The assumption in the model below is that the connection setup procedure between two WTs is split into 
connection setup between the CC and the first WT (WTl), and connection setup between the CC and the 
second WT (WT2). Only the connection setup with the second WT is represented since it does not depend 
on whether the connection was CC initiated or WT initated. 



/Connection', 
$etup_to_WT2' 



RLC DM CONNECT 



RLG DM CONNECT ACK 



RGJo_WT1 



RGJo_WT2; 



SET(T1) 



:=MAX TRIES 



i'Connectivity_ 
Check 



Wait_For_ 
First_Ack 



[Connectivity_\ 
Check ;' 




i:=i-1 



RG_ 
to_WT2 



SET(T1) 




i:=i-1 



RG_ 
to_WT1 



SET(TI) 



/ \ r 

(Disconnected ' 



\ / 



Disconnected 



RLC_DM g6nNECT_C0MPLETE_ACK_ 
from_WT1\ 



RLC_DM CONNECT_COMPLETE_ACK_ 
from_WT2\ 



T1 



RLC_DM_dQNNECT_ 
COMPLETE4o_WT1 



RLC_DM_CiQNNECT_ 
COMPLETE£Jo_WT2 



SET (T2) 



Wait_For_ \ 
First Ack , 



T2 



V 



Wait_For_ 
Second Ack 



Disconnected 

\ / 



l' Wait_For_ 
\ Second Ack 



rlc_dm_g6nnect_complete_ack_ 

from_WT?\ 



Connected 



rlc_dm_g6nnect_complete_ack_ 

from_WT2\ 



T2 



Disconnected 



_/ 



Figure D.I : Power Control - Connectivity Checit - CC side 
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/Connection_ j 
Setup_of_WT2 



Connectivity_ 
Check 



RLC_DM_CONNECT_ACK 



(< 



\ 



Connectivity_ 
Check 



RG_ 
toJhis_W 



RLC_DM_PQWER_CONTROL_ 
to_peer_WT/ 



RG_ 
to_peeM 



SET(T1) 



|WaitJor_PC_ 
\ message 



|Wi 



aitJor_PC_ 
\ message 



RLC_DM p6wER_C0NTR0L_ 
from_peer_VVT 



|ait_Connectiofii_ 
Gomplete_mess 



RG_ 
to_peer 



SET(T1) 



T1 



NACK_ 
to_CC 



RGJoJhislWT 



RLC_DM_P(3WER_C0NTR0L_ 
to_peer_W"I/ 



ait_Coi 
Gomplete_mesi 



nnectiotii_ 



RLC DM CONNECT COMPLETE 



RLC_DM PdWER_CONTROL_ rq ,^ ^^^/^^ 
from_peer_WT ^ ^ 



rlc_dm„c6nnect_complete_ack 



RLC_DM_PQ)A/ER_CONTROL_ 
tc_peer_WT/ 



Connected 



Figure D.2: Power Control - Connectivity Chiecic - WT side 
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Annex E (informative): 

SDL FSIVIs concerning calibration 



NOTE: The following FSMs are only informative. Their aim is to explain the basic idea of how calibration and 
power control work, rather than to give algorithms ready to be implemented. 

Calibration - CC side 



Idle 



Start Measurement 



Start_Repe(rt 



T1 



T3 



RLC_CALIBR>ATION_MEASUREMENT_TRIGGER 'RLC_CALIBRATION_REPORT_TRIGGER 



Set(T1) 



Set(T1) 



Idle 



JC 



Idle 



MbrT rigger ed: 
r(iment_Trlgger^d_WTs" ^ 



' This is a parameter of the 



fJbrTiggered: 
meas. trigger message Rep3rt_triggered_ 



' This is a parameter of the 
WTs ^ rep. trigger message 



Mbr Granted:=0 



Mbr_Granted:=0 



SET(T3) 



' T3 expires at the beginning 
^ of the next mac frame 



SET (T3) 



'T3 expires atthe beginning 
^ of the next mac frame 



Measurement 



J^ 



Report 



Figure E.1 : Calibration CC side - page 1 



I'Measurement 



T3 



T1 



Start_Rep6irt 



k:=Grarrt ed_WTs_in Jastjram e 



Idle 



RLC_CALIBR-ATION_REPORT_TRIGGER 



Nbr GrarTted:=Nbr Granted+k 



SET(TI) 



Nbr_Trig(jered:=Nbr_Trggered-k 



Mbr_Triggered: = 
Report_Trigge red_ WTs 



false 



t5i_Triggere^0- 



True 



SET (T3) 



T3 expires at the 
T beginning 
of the next mac frame 



Idle 



No_Granted:=Ci 



SET (T3) 



Report 



T3 expires at the 

I beginning 

of th e next mac frame 



Figure E.2: Calibration CC side - page 2 
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k:=Grant3d WTs in last frame 



False 




T1 



Idle 



Start Measurement 



RLC CALIBRATION MEASUREMENT TRIGGER 



SET(TI) 



NbrTriggered: = 
Measunjment_Triggen;d_WTs 



Nbr_Granted:=() 



True 



SET (T3) 



SET (T3) 



Idle 



'Measurement 1 



Figure E.3: Calibration CC side - page 3 



Calibration - WT side 



Idle 



RLC CALIBRATION MEASUREMENT TRIGGER 



SET (T4) 



Measurement 



RLC_CALieRATION_REPORT_TRIGGER RG 



SET (T5) 



Report 



Figure E.4: Calibration WT side - page 1 
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I'Measurementl 

\ , / 



RLC_CALt8RATI0N_MEASUREM[;NT_TRIGGER 



LtSR, 



SET (T4) 



T4 



RG 



Idle 



iThis trigger is forTRIGGERED_MACID WT 



RLG_CALfaRATION_REPORT_TRIGGER 



SET(T5) 



Report 



iThis RG is for GRANTED_IVIACID WT 



True 



(TR!GGEREDd\'IACtfcWT_IVIACID) 

^--^ AND > 

(GRANTED_IVrAG+D=WT_MAGID) 



False 



RLC CALIBRATION MEASUREMENT 



TRIGGertEtNMACID 
True GRANTtCM^CID 



Measurpment_and_update_ 
of_locaLRSSj4l)le 



Measurement! 



/ \ 

iMeasurementI 



False 



Measurement 



Figure E.5: Calibration WT side - page 2 



Report 



RLC_CALfBRATION_REPORT_TR'GGER 



T5 



RLC_CALI8RATI0N_MEASUREMENT_TRIGGER 



SET (T5) 



Idle 



RG <--n SET (T4) 



/ 
[Measurement 



-iThis trigger is forTRIGGERED_MACIDWT 



-iThis RGisfor GRANTED MACIDWT 



True 



(TRIGGEREfl_MACie^T_MACID) 

<^ AND / • 

(GRANTED_MACIID=WT_MAC ID) 



False 



RLC_CALIBRATION_REPORT 



TRIGGEfiED:^V|ACID 
True GRANTED JVIACID False 
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( Report j 

\ / 



Report 
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Figure E.6: Calibration WT side - page 3 
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Annex F (informative): 

Specification of the CC probing process in SDL 

The dynamic CC Selection has to prevent different CC-capable devices from becoming CC at the same time. The 
collision resolution mechanism is realized by the CC Probing and Frequency Scan processes that are defined in 
clause 6.7. Both processes are described by a SDL specification, which is depicted in Figure F.l to Figure F.4 and 
documented within this annex. 



Process RLC_Dynamic_CC_Selection 



TIMER 


Probing Period TIMER; |\ 


TIMER 


Probing Frame TIMER; 


TIMER 


Freq Scan TIMER; 


TIMER 


Transm TIMER; 


TIMER 


Transm End TIMER; 


TIMER 


Next Freq TIMER; 



1(4) 




DCL 


K 


Beacon DURATION 


DURATION := 0.000048, 


Start Scan TIME 


DURATION, 


Beacon Send TIME 


DURATION, 


F P 


DURATION := 0.00025, 


P 


DURATION :=0.1, 


T SCAN 


DURATION := 0.001, 


T FS 


DURATION := 0.001, 


Freq No 


INTEGER:=1, 


No Of Freq 


INTEGER:=19, 


Period COUNTER 


INTEGER:=0, 


uniform 


UniformDistribution; 



Start_Scan_TIME:=draw_random{uniform) * P 



Set(now + Start_Scan_TIME, Freq_Scan_TIMER) 




Set(now+P, Probing_Period_TIMER) 



Set(now+F_P Probing_Frame_TIMER) 



Beacon_Send_TIME:=draw_random{uniform) * F_P 



Set{now+Beacon_Send_TIME, Transm_TIMER) 



Probing 



Figure F.l : CC selection - Initialization 
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For the CC Probing and Frequency Scan procedures several timers are needed. Figure F. 1 contains the declaration of 
these timers which are the timers for probing period and probing frame, a timer announcing the transmission of a 
beacon (Transm_TIMER), a timer indicating the beacon fully has been transferred (Transm_End_Timer), a timer 
announcing the start of the scan process {Freq_Scan_TIMER) and a timer indicating the change of the scan frequency 
(Next_Freq_TIMER) . 

Within the declaration the CC selection parameters are also defined and initialized according to the reference values 
introduced in clause 6.7.3.1. The first phase of the CC Probing process is the initialization of the probing period 
introduced by the Period connector. The second phase of the CC Probing is the initialization of the probing frame 
introduced by the Frame connector. 



Process RLC_Dynamic_CC_Selection 



7s 

I LA 

I I 

I I 

I J 



Probing 



Transm TIMER 



/* CC/MT Selection Specification */ 



1\ 



2(4) 



Beacon 



Back off 



Freq_Scan_TIMER 



Set{now+Beacon_DURATION, 
Transm_End_TIMER) 



Set(now+(T_SCAN+T_FS), 
Next_Freq_TIMER) 



Freq_No := 1 



feend_Beacor| 



switchfreq 



^ik_ 



Freq_Scan 



Probing 
I 



Probing_Period_TIMER 



Period_Counter:= 
Period Counter+1 



Probing_Frame_TIMER 






Period Counter>=10 



true 



il^ 



C_Operatioi 



Figure F.2: CC selection - Probing state 
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In the state Probing several signals can be expected, see Figure F.2. A "Probing_Period_Timer" signal indicates the 
beginning of a new probing period, a Probing_Frame_TIMER signal indicates the beginning of a new probing frame 
(virtual frame, not identically to the MAC frame). The reception of a beacon signal from another CC-capable terminal 
induces the terminal to leave the probing process and to accept the other terminal as CC candidate. The Transm_TIMER 
signal is received if the next beacon has to be sent. In this case the timer Transm_End_TIMER is started. Another signal, 
which can occur, is the Freq_Scan_TIMER indicating the beginning of a new frequency scan period. The probing 
process is finished if the PeriodjCOUNTER expires. In this case the terminal becomes a CC. 



Process RLC_Dynamic_CC_Selection 



7. 

I I 

I I 

I I 



Send Beaco 



k3(4) 



/* CC/MT Selection Specification 7 



Probing_Frame_TIIVlER 



'ait for Beacqn 



Transm End TIMER 



Probing 



Transm End TIMER 



Beacon_Send_TIME := draw_random(uniform) * 

(2*F_P-Beacon_Send_TIME-Beacon_Duration) 



Set{now+Beacon_Send_TIME, Transm_TIMER) 



Set{now+F_P Probing_Frame__TIMER) 



il^ 



Probing 



Figure F.3: CC Probing Process - Sending of a Beacon 

The probing process resides in the state Send_Beacon (Figure F.3) after the transmission of the beacon has been 
initiated by sending the beacon signal. If the beacon (CC Probing BCCH) overlaps into the next CC Probing Frame the 
Probing_Frame_TIMER signal is received and the process changes to a state WaitJ^or_Beacon in which the 
Transm_End_TIMER signal is expected. After the beacon has fully been sent (Transm_End_TIMER occurs) the sending 
time of the next beacon is calculated due to the overlap. 

The process changes back to the Probing state after the CC Probing BCCH has been fully sent. 
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Process RLC_Dynamic_CC_Selection 



r ^ 

I I 

I I 

I ] 



Freq_Scan 



k4(4) 



/* CC/MT Selection Specification 7 



j: 



Beacon 



Probing_Period_TIMER 



M^ 



'ait for Scai 



X 



Beacon 



false 



true 




Next_Freq_TIMER 




Next_Freq_TIMER 



Back off 



Freq_No = No_Of_Freq 



false 



Freq_No = 
No_Of_Freq 



Peri5^ounte?>=4a 
^^^^^^"^ true 



false 



Set(now+(T_SCAN+T_FS), Next_Freq_TIMER) 



M/ 



C_Operatioi 



Freq_No := Freq_No + 1 



switcfijreq 



^ 



Start_Scan_TIME := (2*P- 

(Start_Scan_TIME+(T_SCAN+T_FS)*No_of_Freq)) 
*draw_random(uniform) 



Set{now + Start_Scan_TIME, Freq_Scan_TIMER) 



Set(now+P, Probing_Period_TIMER) 



3riod_Counter = 
Period Counter -1 




Figure F.4: CC Probing Process - Frequency Scan 
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The frequency scan (Figure F.4) is started periodically whereby the start time is determined by random. The start time 
of the last frequency scan has been stored in the variable Start_Scan_TIME. To generate the start time of the next 
scanning period it has to be evaluated if the scanning period overlaps into the following probing period. In this case the 
Probing_Period_TIMER is received during the scanning period. The process changes to the WaitJ^or_Scan state. The 
scan procedure finishes equally with a non-overlapping scan process. Afterwards the starting time of the next frequency 
scanning is calculated. The process is then continued at the probing frame initialization, which is symbolized by the 
"Frame" connector. If a beacon signal is received the terminal leaves the probing process and accepts the other terminal 
as CC candidate. The receipt of a Next_Freq_TIMER signal within the scan procedure (state Freq_Scan or 
WaitJ^or_Scan) induces the process to change the operating frequency after the scanning duration T_SCAN. After all 
19 frequencies have been scanned the frequency scan is finished. It is not allowed to scan the frequency channels in 
order. The index Freq_No shall be mapped randomly onto the different usable frequency channels. The receipt of a 
Transm_TIMER indicating the start of beacon transmission is ignored during the scan procedure. 
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Annex G (informative): 

Specification of the CC responsibility handover process in 

SDL 

In this annex the SDL specification for the CC ResponsibiUty Handover is presented. The primitive initiating the CC 
Handover called CCH_cc_ho_request_req is received in the Associated state within the current CC (Figure G.l). Upon 
reception of the primitive the RLC_CC_HO_REQUEST PDU is sent to all WTs in the subnet and the CC changes to 
the state Centi-al_Controller_Handover_Requested. In this state the RLC_CC_HO_REQUEST_ACK PDU is expected. 
If this PDU comes in, the CCH_cc_ho_request_cnf primitive is sent to the RLC environment. Afterwards a 
RLC_CC_HO_NOTIFY PDU is sent to all WTs. This is represented in the SDL diagi-am by a loop from 
MaxMacId to 0. If the signal has been sent to all WT MAC Ids the CCH_start_cl_ho_ind primitive is sent to all CLs 
and the CC goes into the state RLC_Stopped. 



PROCESS TYPE PTCC 



1(4) 



/* CC specific Specification */ 



N 



DCL 

count_mac INTEGER := IVIaxlVlacId, 
retransCounter INTEGER ■- MaxRetransmissions; 



SSOCIATEI 



A Ce/ntral_Control^i 

j Handover_Reque6l 



CCH_cc 
request_r^ 



RLC_CC 
REQUES' 



RLC_CC 
REQUEST 



CK 



CCH_cc_hi 
request_cnf 



SET (T_cc_ho_rec _cc) 



RLC_CC 
NOTIFY 



Ce[ntral_Controllter_ 
Handover_RequeBted 



-JonDLRBCH 



CCH_start\ho_ind 



RESET(T_cc_ho_r£ q_cc) 



RLC_ 
Stopped 



L-l Indication to CL 



TIMER 
T_cc_ho_req_cc; 



H Exception 



CC HO failed, 

try another candidate 




Ce|fitral_Controliy_ 
HarWover_Requelsted 



^SSOCIATEQ 



Figure G.l : CC Responsibility l-landover - SDL specification of CC, page 1 

In the state RLC_stopped only the CC Handover procedure goes on at RLC level. The CC waits to receive the primitive 
CCH_start_cl_ho_rsp from the environment. After reception of this primitive the CC first starts to release all 
connections in CM of all WTs (see Figure G.2). If all connections in CM are released, the CC goes into the state 
Wait for ho start. 
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PROCESS TYPE PTCC 



2(4) 



L-Si 



I 



/* CC specific Specification */ 



TIMER 
tiReleaselni 



DCL 1^^ 

l\/laxAcl<Time DURATION 
DataAckTime DURATION 



RLC_ 
Stopped 



CCH_star^_ho_rsp 



SE]r( Mow+MaxAck Time, 
tlReleaselnd) 



FALSE 




RLC_RELEASE 
(dlccjdjist^ 

release cadse) TO dice id 



TRUE 



JOnly DL/UL 
] Connections 

I 



Wait_for_ 
ho start 



TAlfULand DL 

-| Connections 

I released 

I 



Release_ 
Initiated 



RLC_Rele3€e_ACK 
(diccjd 



1 



tlReleaselra 



count_mac := 
(bount mac - 1 



Figure G.2: CC Responsibility l-landover - SDL specification of CC, page 2 

In the state Wait_for_ho_start, the CCH_start_cc_req primitive is expected. If it comes in, the data transfer procedure is 
started (Figure G.3). For the data transfer a Go-Back-N ARQ protocol is applied. The CC knows how many 
RLC_CC_TRANS_CC_DATA PDUs are necessary to transmit all data to the CC-candidate. This number of PDUs is 
stored in the parameter pduToSend. The variable count_pduToSend in Figure 3 gives the number of PDUs that still 
have to be sent in the course of the procedure. At the beginning of the data transfer count_pduToSend is set to the value 
pduToSend. In each frame a certain number of RLC_TRANS_CC_DATA PDUs is transmitted in one packet train. How 
many PDUs are transmitted in a row is out of the scope of the present document. This is why the implementation of the 
function calcOptPduInARow is left open in Figure 3. Depending on how many PDUs still have to be send and probably 
also on the current traffic load the function calcOptPduInARow determines the value of the variable optPduInARow. 
Then the optPduInARow number of PDUs is transmitted by the loop that is controlled by the variable count_pduInRow. 
With each transmitted PDU the sequence number sn is incremented by 1 . If the PDU is the last PDU of the whole data 
transfer (count_pduInRow = 1 and count_pduToSend = optPduInARow), then the ext_ind field is set to (false). 
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If all PDUs of the packet train have been transmitted, the CC sets a timer for the acknowledgement and goes to the state 
Data_Send. In this state either the RLC_TRANS_CC_DATA_ACK arrives or the timer runs out. In case the 
RLC_TRANS_CC_DATA_ACK has arrived, the CC checks whether the RR_flag included in the PDU is true or false. 
If the RR_flag is false, the CC retransmits from the signalled snAck number on (this is done by setting sn = snAck). If 
the RR_flag is true, this means that all PDUs up to snAck have been correctly received. In this case the CC just sets the 
count_pduToSend parameter to the new value. It does not retransmit PDUs from snAck+1 on, but continues with 
transmission of PDU sn (sn is unchanged). A special case occurs if snAck is equal to 0. This indicates that the last 
RLC_TRANS_CC_DATA PDU of the whole procedure has been correctly received by the CC-candidate and that the 
CC can change to the state CC_Start_Initiated. 

In case the timer for the acknowledgement (T_trans_cc_data_cc) runs out, the CC retransmits the last optPduInARow 
PDUs (this is done by setting sn = sn - optPduInARow). 



PROCESS TYPE PTCQ 




Figure G.3: CC Responsibility l-landover - SDL specification of CC, page 3 
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In the state CC_Start_Initiated the RLC_START_CC_ACK PDU is expected from the CC-candidate (Figure G.4). If 
this PDU arrives, the CC sends the CCH_start_cc_cnf primitive to the RLC environment, reables its RLC and becomes 
a normal WT. 



PROCESS TYPE PTCC 



4(4) 






CC_Start_ 
Initiated 



RLC_STAI 
CC ACK 



CCH_start_^_cnf 



RE£ET(T_start_cc_cc) 




CC HO failed, 
restart the whole proc. 



True 



Reable RLC |-- 



I 



ioing_To_Be 
An Mt 



nitransCounter: 
re ransCounter - 



SET(T_start_cc_ 



«) 



CC_Start_ 
Initiated 



KSSOCIATEI 



Figure G.4: CC Responsibility l-landover - SDL specification of CC, page 4 

The SDL specification of CC Handover on the WT side of an H/2-HD (resp. on MT side in the basic SDL model) is 
divided in two parts. The first part in Figure G.5, Figure G.6 and Figure G.7concerns a WT that is selected as 
CC-candidate. The second part in Figure G.8 refers to all other WTs in the subnet. 

In Figure G.5 the CC-candidate receives the RLC_CC_HO_REQUEST PDU in the Associated state. Upon reception 
the candidate generates a CCH_cc_ho_request_ind primitive that is sent to the RLC environment and the candidate 
changes to the CC_Handover_Indicated state. In this state the CC-candidate waits for the response primitive of the RLC 
environment to send an RLC_CC_HO_REQUEST_ACK to the CC. 
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PROCESS TYPE PTWT 



1(4) 



L-Si 



/* CC_Candidate specific Specification 



^ 



fVSSOCIATEI3 



C_Handoverl 
Indicated T 



RLC_CC 
HO REQI 



ST 



CCH_cc 
request_rsl 



CCH_cc_h( 
requestjnd 



RLC_CC_i^ 
REQUEST/5K 



C_Handover' 
Indicated 



_ik_ 



(CC_Handover\_ 
RcknowledgeoT 



Figure G.5: CC Responsibility Handover - SDL specification of CC-candidate WT, page 1 

The CC-candidate is now in the state CC_Handover_Acknowledged. In this state the RLC_RELEASE PDUs sent by 
the CC are received (see Figure G.6 left corner). They are indicated to the CL with an appropriate primitive and in the 
state Release_Indicated_Cand the CC-candidate waits for a response primitive of the CL. If the response is received, the 
candidate changes to the state Wait_For_CC_Data. 

NOTE: The CC-candidate is a regular WT and may therefore also have ongoing CM connections that have to be 
released. 

In the state Wait_For_CC_Data either a RLC_TRANS_CC_DATA PDU sent by the CC is received, or the 
acknowledgement timer tiAckInd runs out. This timer is not specified but it shall have a value less than 2 ms, to 
guarantee that at least one acknowledgement is sent per frame. All PDUs received within one frame are certainly 
contained in the same packet train. Therefore the inter-arrival time in between RLC_TRANS_CC_DATA PDUs of the 
same frame is very short. Due to this fact, the tiAckInd timer could even have a much shorter value than 2 ms. If in a 
short time after a PDU arrival, no further PDU is recognized, this probably means that the PDU has been the last 
RLC_TRANS_CC_DATA PDU in the frame and an acknowledgement should be generated. 

If a RLC_TRANS_CC_DATA PDU arrives, first of all the tiAckInd timer of the previous PDU is stopped. In case the 
received PDU is the expected one (snAck = sn - 1) and not the last one (ext_ind = TRUE), a new tiAckInd timer is 
started. In all other cases the acknowledgement is directly sent and therefore no timer is needed. One of these other 
cases is that the received PDU is not the expected one (snAck ?t sn - 1). If this occurs a negative acknowledgement is 
generated (RR_flag = FALSE). A last case consists of the received PDU being the last RLC_TRANS_CC_DATA PDU 
of the whole CC Handover procedure (ext_ind = 0). In this case a positive acknowledgement is sent to the CC with the 
snAck value set to 0. A snAck value of indicates to the CC that the data transfer has been successfully completed. 
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PROCESS TYPE PTWT 



C_Handover 
,cknowledgei 



/* CC_Candidate specific Specification V 



RLC_RELE 
(diccjdjis 



feE 
release cause 



Release. ^ _JOnly DL/UL 
ihdicated Canff i Connections 



DUC_relea 
(DUC_REt 



5e_rsp 
=ASE_ACK_ARG) 



DUC_relea 
(DUC_RELI 



nd 
SE_ARG) 



RLC_REL^ASE_ACK 
(dlccJdJisJK 



/ Release^ 
i|ndicated_Cani 



Wait_For_ 
CC Data 



FALSE 



TRUE 



snAck := 
snAck + 1 



TRUE 



SET(N|Dw+WaitForA(jkTime 
tiAckInd) 




2(4) 



DCil t^ 

sn INTEGER :=1, 
snAck INTEGER := 0, 
extjnd BOOL := FALSE, 
WaitForAckTime DURATION, 
RRJIag BOOL := TRUE, 
timerExists BOOL ■- FALSE; 



TIMER 
tlAcklnd; 



"X 



/* set to less than 2 ms, because 
one ack per frame */ 



Wait_for_ 
CC Data 



RLC_TRA^ 
CC_DATA< 
(sn, ext ind> 




Reset(tiAcklndl 



tiAckInd 



RRJIag := TRUE; 




FALSE 



RLC_TRANS_ 
CC DATA y 
ACRfsnAck ^RR flaa) 



RFUIag:= FALSE 



FALSE 



RR 



snAck ■- 0; 
.flag ;= TRUE 



timerExists := 
TRUE 



RLC_TRAIMS_ 
CC_DATA_> 
ACKfspAck fRR flag) 



RLC_TRANS_ 
CC_DATA_ > 
ACK{snAs)<RR_flag) 



timerExists :-- 
FALSE 



timerExists : 
FALSE 



e* 



snAck ■- 1 ; 
snAck ■- 1 ; 
:t ind ■- FALSE 



M/ 



( Data_Send j 



Figure G.6: CC Responsibility Handover - SDL specification of CC-candidate WT, page 2 

In the state Data_Send the CC-candidate waits for the RLC_START_CC PDU from the CC (Figure G.7). Upon 
reception of the PDU a CCH_start_cc_ind is sent to the environment. The environment responds with a 
CCH_start_cc_rsp while the CC-candidate RLC layer is in the state CC_Start_indicated. If the RLC receives the 
response of the environment it sends a RLC_START_CC_ACK PDU to the old CC and starts CC operation at the 
requested time. Furthermore a RLC_CC_START_OPERATION is sent out in broadcast mode to inform all WTs about 
the take over of CC functionality. 
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PROCESS TYPE PTWT 










3(4) 


1 1 
1 1 
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specific Specification */|\ 
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CCH_start/ 
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ccjnd 
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( CC_Start_ \ 
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OPERATION 








\^ 




/ \ 
CC_Started 

\ / 













Figure G.7: CC Responsibility Handover - SDL specification of CC-candidate WT, page 3 

Figure G.8 finally gives an overview over the CC Handover specific processes inside a WT that is not a CC-candidate. 
After the reception of the RLC_CC_HO_NOTIFY PDU the WT goes into the state RLC_Stopped_MT. In this state the 
WT waits for the RLC_RELEASE requests for its CM connections. After indication and response to/from the CL, the 
WT changes to the state Connections_Released_MT. If no RLC_RELEASE requests are received, e.g. in the case 
where the WT only maintains DM connections, the WT directly changes to the state Connections_Released_MT after 
the timer tiNoReleases has run out. In the state Connections_Released_MT the WT receives the 
RLC_CC_START_OPERATION message and goes back to its basic state Associated. 
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PROCESS TYPE PTWT 



/* WT specific Specification 7| 



DCL 
tiNoReleases DURATIOI 



ftSSOCIATED 



RLC_ 
Stopped_l\/IT 



RLC_CC_ 
HO NOT! 



RLC_RELEASE 
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Figure G.8: CC Responsibility Handover - SDL specification of WT, page 4 
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Annex H (informative): 

Example of valid Reed-Solomon word 

The following RS word is built from 4 consecutive PDUs. These PDUs are normal LCH, hence the PDU-type is set to 
00. The sync field is inverted for the first PDU. The other bits of the first octet are set to zero. The contents of the other 
octets of the PDUs are explained in table H.l. 

Table H.l 





PDU#1 


PDU#2 


PDU#3 


PDU#4 


PDU type 


00 


00 


00 


00 


Sync field 


11 


00 


00 


00 


Octet #i value 
(from i = 2 to 50) 


1 


50+i 


100+i 


150+i 



The following RS word has been obtained from these 4 PDUs payload with padding 39 0-bytes in front of the 
200 payload bytes and applying the RS(239,255). The redundancy is in bold. 

Table H.2 





PDU#1 


PDU#2 


PDU#3 


PDU#4 


Octet #1 


48 











Octet #2 


2 


52 


102 


152 


Octet #3 


3 


53 


103 


153 


Octet #4 


4 


54 


104 


154 


Octet #5 


5 


55 


105 


155 


Octet #6 


6 


56 


106 


156 


Octet #7 


7 


57 


107 


157 


Octet #8 


8 


58 


108 


158 


Octet #9 


9 


59 


109 


159 


Octet #10 


10 


60 


110 


160 


Octet #1 1 


11 


61 


111 


161 


Octet #12 


12 


62 


112 


162 


Octet #13 


13 


63 


113 


163 


Octet #14 


14 


64 


114 


164 


Octet #15 


15 


65 


115 


165 


Octet #16 


16 


66 


116 


166 


Octet #17 


17 


67 


117 


167 


Octet #18 


18 


68 


118 


168 


Octet #19 


19 


69 


119 


169 


Octet #20 


20 


70 


120 


170 


Octet #21 


21 


71 


121 


171 


Octet #22 


22 


72 


122 


172 


Octet #23 


23 


73 


123 


173 


Octet #24 


24 


74 


124 


174 


Octet #25 


25 


75 


125 


175 


Octet #26 


26 


76 


126 


176 
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